Nixpkgs security tracker

Login with GitHub
⚠️ You are using a production deployment that is still only suitable for demo purposes. Any work done in this might be wiped later without notice.

Dismissed suggestions

These automatic suggestions were dismissed after initial triaging.

to select a suggestion for revision.

View:
Compact
Detailed
Dismissed
(no matching packages found)
Permalink CVE-2026-72743
5.1 MEDIUM
  • CVSS version (CVSS): 4.0
  • Attack Vector (AV): Network (N)
  • Attack Complexity (AC): Low (L)
  • Attack Requirement (AT): None (N)
  • Privileges Required (PR): Low (L)
  • User Interaction (UI): Passive (P)
  • Vulnerable System Impact Confidentiality (VC): None (N)
  • Vulnerable System Impact Integrity (VI): None (N)
  • Vulnerable System Impact Availability (VA): None (N)
  • Subsequent System Impact Confidentiality (SC): Low (L)
  • Subsequent System Impact Integrity (SI): Low (L)
  • Subsequent System Impact Availability (SA): None (N)
  • Modified Attack Vector (MAV): Network (N)
  • Modified Attack Complexity (MAC): Low (L)
  • Modified Attack Requirement (MAT): None (N)
  • Modified Privileges Required (MPR): Low (L)
  • Modified User Interaction (MUI): Passive (P)
  • Modified Vulnerable System Impact Confidentiality (MVC): None (N)
  • Modified Vulnerable System Impact Integrity (MVI): None (N)
  • Modified Vulnerable System Impact Availability (MVA): None (N)
  • Modified Subsequent System Impact Confidentiality (MSC): Low (L)
  • Modified Subsequent System Impact Integrity (MSI): Low (L)
  • Modified Subsequent System Impact Availability (MSA): Negligible (N)
  • Safety (S): Not Defined (X)
  • Automatable (AU): Not Defined (X)
  • Recovery (R): Not Defined (X)
  • Value Density (V): Not Defined (X)
  • Vulnerability Response Effort (RE): Not Defined (X)
  • Provider Urgency (U): Not Defined (X)
  • Confidentiality Req. (CR): Not Defined (X)
  • Integrity Req. (IR): Not Defined (X)
  • Availability Req. (AR): Not Defined (X)
  • Exploit Maturity (E): Not Defined (X)
created 3 weeks, 6 days ago Activity log
  • Created & dismissed (no matching packages found) suggestion
SQLBot 1.10.0 SQText Dashboard Component Stored XSS via v-html

SQLBot through 1.10.0, fixed in commit c3f40a5, contains a stored cross-site scripting vulnerability in the SQText dashboard component that renders TinyMCE output via v-html without sanitization. Attackers who can modify dashboard text widget content can inject arbitrary HTML and JavaScript that executes for all users viewing the dashboard.

References

Affected products

SQLBot
  • =<1.10.0
  • ==c3f40a5c05a53253b2924765b02b83f6a819948f
Dismissed
(no matching packages found)
Permalink CVE-2026-72919
4.3 MEDIUM
  • CVSS version (CVSS): 3.1
  • Attack Vector (AV): Network (N)
  • Attack Complexity (AC): Low (L)
  • Privileges Required (PR): Low (L)
  • User Interaction (UI): None (N)
  • Scope (S): Unchanged (U)
  • Confidentiality (C): None (N)
  • Integrity (I): Low (L)
  • Availability (A): None (N)
  • Modified Attack Vector (MAV): Network (N)
  • Modified Attack Complexity (MAC): Low (L)
  • Modified Privileges Required (MPR): Low (L)
  • Modified User Interaction (MUI): None (N)
  • Modified Confidentiality (MC): None (N)
  • Modified Scope (MS): Unchanged (U)
  • Modified Integrity (MI): Low (L)
  • Modified Availability (MA): None (N)
created 3 weeks, 6 days ago Activity log
  • Created & dismissed (no matching packages found) suggestion
Rocket.Chat: Broken Access Control in channels.convertToTeam Allows Unauthorized Conversion of Public Channels into Teams

Rocket.Chat is an open-source, secure, fully customizable communications platform. Prior to 7.10.14, 8.0.8, 8.1.7, 8.2.7, 8.3.7, 8.4.5, 8.5.2, and 8.6.1, the channels.convertToTeam REST endpoint allows an authenticated registered user with the create-team permission to convert an unrelated public channel by supplying channelName instead of channelId because the edit-room permission is checked only for channelId. This issue is fixed in versions 7.10.14, 8.0.8, 8.1.7, 8.2.7, 8.3.7, 8.4.5, 8.5.2, and 8.6.1.

Affected products

Rocket.Chat
  • ==>= 8.4.0, < 8.4.5
  • ==>= 8.6.0, < 8.6.1
  • ==>= 8.1.0, < 8.1.7
  • ==>= 8.0.0, < 8.0.8
  • ==>= 8.2.0, < 8.2.7
  • ==< 7.10.14
  • ==>= 8.3.0, < 8.3.7
  • ==>= 8.5.0, < 8.5.2
Dismissed
(no matching packages found)
Permalink CVE-2026-17022
7.5 HIGH
  • CVSS version (CVSS): 3.1
  • Attack Vector (AV): Network (N)
  • Attack Complexity (AC): Low (L)
  • Privileges Required (PR): None (N)
  • User Interaction (UI): None (N)
  • Scope (S): Unchanged (U)
  • Confidentiality (C): High (H)
  • Integrity (I): None (N)
  • Availability (A): None (N)
  • Modified Attack Vector (MAV): Network (N)
  • Modified Attack Complexity (MAC): Low (L)
  • Modified Privileges Required (MPR): None (N)
  • Modified User Interaction (MUI): None (N)
  • Modified Confidentiality (MC): High (H)
  • Modified Scope (MS): Unchanged (U)
  • Modified Integrity (MI): None (N)
  • Modified Availability (MA): None (N)
created 3 weeks, 6 days ago Activity log
  • Created & dismissed (no matching packages found) suggestion
Salon Booking System – Free Version <= 10.30.33 - Unauthenticated Booking Information Disclosure via Booking Wizard

The Salon Booking System WordPress plugin through 10.30.33 does not properly validate a booking's ownership token before loading it in its booking-wizard confirmation steps, allowing unauthenticated attackers to disclose other customers' booking records, including personal information, by supplying a sequential booking identifier.

References

Affected products

Salon Booking System
  • =<10.30.33
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 6 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
gve: fix Rx queue stall on alloc failure

In the Linux kernel, the following vulnerability has been resolved: gve: fix Rx queue stall on alloc failure When the system is under extreme memory pressure, page allocations can fail during the Rx buffer refill loop. If the number of buffers posted to hardware falls below a critical low threshold and the refill loop exits due to allocation failures, the queue can stall: 1. The device drops incoming packets because there are no descriptors. 2. Since no packets are processed, no Rx completions are generated. 3. Because no completions occur, NAPI is never scheduled, preventing the refill loop from running again even after memory is freed. This results in a permanent queue stall. Resolve this by introducing a starvation recovery timer for each Rx queue. If the number of buffers posted to hardware falls below a critical low threshold, start a timer to periodically reschedule NAPI. Once NAPI runs and successfully refills the queue above the threshold, the timer is not rescheduled. The threshold is set to 32 because a single maximum-sized Receive Segment Coalescing (RSC) packet can consume up to 19 descriptors in the Rx path. Lower thresholds (such as 8 or 16) would be insufficient to process a complete maximum-sized RSC packet, risking packet drops or unexpected hardware behavior under memory pressure. Setting the threshold to 32 guarantees a safe margin to handle at least one full RSC packet.

Affected products

Linux
  • <0c317349b4baa5038d1fc373bf46d5a2419d1710
  • <91e0249f3ef62b75fe8c9c9372eaba32876e4b3a
  • <689b9f588d2d7323dc66293fe594a68d030f400f
  • =<6.6.*
  • =<*
  • <b65352a1bac64442ad95e64f385b40ccb9f1b0db
  • ==5.14
  • =<6.18.*
  • =<6.12.*
  • =<7.1.*
  • <299d5728a7312fdd02059b074aebbe4ebbd391e4
  • <5.14
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 6 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
firewire: net: Fix fragmented datagram reassembly

In the Linux kernel, the following vulnerability has been resolved: firewire: net: Fix fragmented datagram reassembly fwnet_frag_new() keeps a sorted list of received fragments for a partial datagram. When a new fragment is adjacent to an existing fragment, the code checks whether the new fragment also closes the gap to the next or previous list entry. Those neighbor lookups currently assume that the current fragment always has a real next or previous fragment. At a list edge, the next or previous entry is the list head, not a struct fwnet_fragment_info. The gap checks also compare against the old edge of the current fragment instead of the edge after adding the new fragment. As a result, a fragment that bridges two existing ranges may leave two adjacent ranges unmerged, so fwnet_pd_is_complete() can miss a complete datagram. Check for the list head before looking up the neighboring fragment, and compare the neighbor against the new fragment's far edge when deciding whether to merge all three ranges. This issue was found by a static analysis checker and confirmed by manual source review.

Affected products

Linux
  • <0177e578d7a885037b0fb82286c12e9d0360cc10
  • <d52a13adbb8ccbab99cd3bad36804e87d8b5c052
  • <2.6.31
  • =<6.6.*
  • =<*
  • ==2.6.31
  • =<6.18.*
  • =<6.12.*
  • <2a5aa4e9b89227d1a1690fb8d5b81e5f3b261999
  • <22e05b8ddbcf7d22c7f1598786e86635547e554d
  • =<7.1.*
  • <b7d633c7c92321be98724b1d365e8ce507f2f349
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 6 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
tracing: Delay module ref count for "enable_event" trigger

In the Linux kernel, the following vulnerability has been resolved: tracing: Delay module ref count for "enable_event" trigger Triggers are now delayed from freeing, but can still be triggered until after the RCU grace period has ended. The freeing of the enable_event data is put into the private_data_free() callback, but the put of the module refcount is done immediately. It is possible that if a module is removed that has an event that would enable (or disable) it is still active, it can read the data of the module after it is removed causing a use-after-free bug. Move the trace_event_put_ref() that releases the module into the delayed callback so that the module can not be removed until any reference to its events are finished.

Affected products

Linux
  • <e091351b38818ef620d27f44f4bfd625f13afbff
  • =<*
  • ==6.19
  • <159fdc3e01dca5fdbc412fcd8b239895733a270d
  • =<7.1.*
  • <6.19
Dismissed
(no matching packages found)
created 3 weeks, 6 days ago Activity log
  • Created & dismissed (no matching packages found) suggestion
The OpenCart v4.2.0.0 extension installer contains a directory traversal vulnerability

OpenCart extensions are uploaded as zip files with .ocmod.zip extensions. Upon installation, the OpenCart v4.2.0.0 extension installer extracts these zip files, but does not validate that the extracted paths stay inside the intended extraction directory. An attacker can craft a malicious extension containing file path traversal sequences, such as ../. With this vulnerability, an attacker can write files, such as a PHP web shell, into the webroot directory.

Affected products

OpenCart
  • ==4.2.0.0
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 6 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
ksmbd: validate ACE size against SID sub-authorities

In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate ACE size against SID sub-authorities set_ntacl_dacl() validates sid.num_subauth before copying an ACE, but does not verify that the declared ACE size contains all sub-authorities described by that field. An undersized ACE can therefore be copied and later make the POSIX ACL deduplication walk inspect data beyond the copied ACE boundary. The existing initial bound check is also too small. It only ensures that the ACE size field is accessible before set_ntacl_dacl() reads sid.num_subauth farther into the input buffer. Require enough input for the fixed SID header before accessing num_subauth, reject ACEs smaller than that header, and skip ACEs whose declared size cannot contain the complete SID. This makes the validation consistent with the other ACE walk paths.

Affected products

Linux
  • <61fd3559199f7fa693dcbff35e59477e24af041a
  • <7.1.6
  • <6.12.101
  • =<6.6.*
  • <62d80d7c2d9428085e7458ad4c06ca8c0984039b
  • =<*
  • <6.6.148
  • <5152c6d49e3fd4e9f2e857c57527aead752f1f87
  • <b7cb5bf0855470799f12da825de91e48951b3876
  • <6.18.42
  • =<6.12.*
  • =<6.18.*
  • =<7.1.*
  • <337022d9dfac441c3b35e4455a51aa981996e02e
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 6 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
wifi: cfg80211: bound element ID read when checking non-inheritance

In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: bound element ID read when checking non-inheritance cfg80211_is_element_inherited() reads the first data octet of the candidate element (id = elem->data[0]) to look it up in an extension non-inheritance list. It does so after testing elem->id, but without verifying that the element actually has a data octet. A zero-length extension element (WLAN_EID_EXTENSION with length 0) therefore makes it read one octet past the end of the element. _ieee802_11_parse_elems_full() runs this check for every element of a frame once a non-inheritance context exists -- e.g. while parsing a per-STA profile of a Multi-Link element in a (re)association response, or a non-transmitted BSS profile -- so a crafted frame from an AP can trigger a one-octet slab-out-of-bounds read during element parsing: BUG: KASAN: slab-out-of-bounds in cfg80211_is_element_inherited Read of size 1 ... in net/wireless/scan.c Return early (treat the element as inherited) when an extension element carries no data, mirroring the existing handling of empty ID lists. The bug was found by fuzzing ieee802_11_parse_elems_full() under KASAN.

Affected products

Linux
  • <cb8afea4655ff004fa7feee825d5c79783525383
  • =<6.6.*
  • <11ac7a5e75f5132f1778e0c60981d30dc29fb869
  • =<*
  • <5.2
  • <20c308d9a57722801961f816395bf825f7bde6bc
  • =<6.12.*
  • =<6.18.*
  • =<7.1.*
  • <ddf2773bcc8e49a43c561f22ec1e7924215d7947
  • ==5.2
  • <84bd907361c56fbd5523eceb2682cb39da059bd5
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 6 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
drm/amdgpu: Fix context pstate override handling

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix context pstate override handling There are several problems in the context pstate handling code. The most serious ones are potential use-after-free and NULL pointer dereferences at context initialization time. Both are due amdgpu_ctx_init() not holding the adev->pm.stable_pstate_ctx_lock, which is otherwise used from both sysfs and the context code itself for modifying and clearing the stored context pointer. Second issue is that context fini can trample over the pstate configuration set via sysfs. This is due the restore state (ctx->stable_pstate) being saved at context init time, and not if, or when the context actually changes the pstate. As the context exits it will therefore incorrectly restore to what was set before the sysfs override was requested. The simplest fix is to drastically simplify how the state is tracked, by clearly defining the points at which pstate ownership is taken and released, and to handle all transitions under the correct lock. Instead of at context init time, the previous state is saved only at the point the context overrides the current state, and is restored on context exit only if the context is still the owner of the current override state. (cherry picked from commit 1b5e413713c0a93bc1818394d0ce49aaad21bd27)

Affected products

Linux
  • ==6607901fce79959130db485e7549dacaaeef034e
  • ==6.1
  • <6.1
  • <9f9c88eb298c54348be3ca4087f4f4c615065b87
  • =<*
  • <c1dc4ccb82c9e56325d8e7514ca4c90bd1efb351
  • =<6.18.*
  • <23a8726e1d7597fe7c9a59d5dc42ba8b7d345b8a
  • =<6.12.*
  • =<7.1.*
  • <6.1
  • <e06c39cc1c48dca68a5ffd971c23025a52d46634