Nixpkgs security tracker

Login with GitHub

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-44584
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 6 days, 2 hours ago Activity log
  • Created & dismissed (no matching packages found) suggestion
Paymenter doesn't reset email verification status after email change

Paymenter is a free and open-source webshop solution for management of hosting services. In versions prior to 1.5.0, the email update functionality fails to invalidate the existing verification state when a user changes their email address, allowing a verified account to retain its verified status after switching to an unverified or unowned email address. When a user updated their email address, the system did not reset or revalidate the associated email verification status. As a result, the verification column remained set to “true” even after the email address was changed. Exploitation could potentially result in: misrepresentation of email ownership, bypass of verification-based trust assumptions, and abuse of features gated behind verified status. No direct unauthorized access to other users accounts or data is possible through this issue alone. This issue has been fixed in version 1.5.0.

Affected products

Paymenter
  • ==< 1.5.0
Dismissed
(max. allowed matches exceeded)
Permalink CVE-2026-63842
7.8 HIGH
  • CVSS version (CVSS): 3.1
  • Attack Vector (AV): Local (L)
  • Attack Complexity (AC): Low (L)
  • Privileges Required (PR): Low (L)
  • User Interaction (UI): None (N)
  • Scope (S): Unchanged (U)
  • Confidentiality (C): High (H)
  • Integrity (I): High (H)
  • Availability (A): High (H)
  • Modified Attack Vector (MAV): Local (L)
  • Modified Attack Complexity (MAC): Low (L)
  • Modified Privileges Required (MPR): Low (L)
  • Modified User Interaction (MUI): None (N)
  • Modified Confidentiality (MC): High (H)
  • Modified Scope (MS): Unchanged (U)
  • Modified Integrity (MI): High (H)
  • Modified Availability (MA): High (H)
created 6 days, 2 hours ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
drm/amdgpu/jpeg: set no_user_fence for JPEG v5.0.0 ring

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/jpeg: set no_user_fence for JPEG v5.0.0 ring JPEG rings do not support 64-bit user fence writes, reject CS submissions with user fences. (cherry picked from commit 0f43893d3cd478fa57836697525b338817c9c23d)

Affected products

Linux
  • <3a55ff19a6ff5e046d6a4a18e36deec5d95d9a2e
  • <69ab75c7c5f378eb46f4c918aa848bb5c5603924
  • =<6.18.*
  • <6.9
  • <a7e63bb93a7fde3c8920984c3deee9acfe461562
  • =<7.0.*
  • =<6.12.*
  • =<*
  • <ea7c61c5f895e8f9ea0ffffa180498ef9c740152
  • ==6.9
Dismissed
(no matching packages found)
Permalink CVE-2026-60032
9.4 CRITICAL
  • CVSS version (CVSS): 4.0
  • Attack Vector (AV): Network (N)
  • Attack Complexity (AC): Low (L)
  • Attack Requirement (AT): None (N)
  • Privileges Required (PR): High (H)
  • User Interaction (UI): None (N)
  • Vulnerable System Impact Confidentiality (VC): High (H)
  • Vulnerable System Impact Integrity (VI): High (H)
  • Vulnerable System Impact Availability (VA): High (H)
  • Subsequent System Impact Confidentiality (SC): High (H)
  • Subsequent System Impact Integrity (SI): High (H)
  • Subsequent System Impact Availability (SA): High (H)
  • Modified Attack Vector (MAV): Network (N)
  • Modified Attack Complexity (MAC): Low (L)
  • Modified Attack Requirement (MAT): None (N)
  • Modified Privileges Required (MPR): High (H)
  • Modified User Interaction (MUI): None (N)
  • Modified Vulnerable System Impact Confidentiality (MVC): High (H)
  • Modified Vulnerable System Impact Integrity (MVI): High (H)
  • Modified Vulnerable System Impact Availability (MVA): High (H)
  • Modified Subsequent System Impact Confidentiality (MSC): High (H)
  • Modified Subsequent System Impact Integrity (MSI): High (H)
  • Modified Subsequent System Impact Availability (MSA): High (H)
  • 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 6 days, 2 hours ago Activity log
  • Created & dismissed (no matching packages found) suggestion
Joomla Extension - themexpert.com - Authenticated arbitrary file upload in JMedia < 1.6.0

The Joomla extension JMedia is vulnerable to an authenticated arbitrary file upload, leading to RCE. Executable uploads/writes possible (incl. polyglot filenames); chmod didn't strip execute bits.

Affected products

JMedia extension for Joomla
  • ==1.0-1.5.4
Dismissed
(max. allowed matches exceeded)
Permalink CVE-2026-63918
7.8 HIGH
  • CVSS version (CVSS): 3.1
  • Attack Vector (AV): Local (L)
  • Attack Complexity (AC): Low (L)
  • Privileges Required (PR): Low (L)
  • User Interaction (UI): None (N)
  • Scope (S): Unchanged (U)
  • Confidentiality (C): High (H)
  • Integrity (I): High (H)
  • Availability (A): High (H)
  • Modified Attack Vector (MAV): Local (L)
  • Modified Attack Complexity (MAC): Low (L)
  • Modified Privileges Required (MPR): Low (L)
  • Modified User Interaction (MUI): None (N)
  • Modified Confidentiality (MC): High (H)
  • Modified Scope (MS): Unchanged (U)
  • Modified Integrity (MI): High (H)
  • Modified Availability (MA): High (H)
created 6 days, 2 hours ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
l2tp: use refcount_inc_not_zero in l2tp_session_get_by_ifname

In the Linux kernel, the following vulnerability has been resolved: l2tp: use refcount_inc_not_zero in l2tp_session_get_by_ifname A reader in l2tp_session_get_by_ifname() can return a pointer to a session whose refcount has reached zero. The getter takes its reference with plain refcount_inc(), but every other session getter in the same file (l2tp_v2_session_get, l2tp_v3_session_get, and the corresponding _get_next variants) uses refcount_inc_not_zero() because the IDR/RCU lookup can race with refcount_dec_and_test() -> l2tp_session_free() -> kfree_rcu(). The ifname getter is the only outlier; the inconsistency was raised on-list after 979c017803c4 ("l2tp: use list_del_rcu in l2tp_session_unhash"). A reader inside rcu_read_lock_bh() that matches session->ifname can be preempted between the strcmp() and the refcount_inc(). If the last reference drops on another CPU in that window, the reader's refcount_inc() runs on a counter that has reached zero. refcount_t catches the addition-on-zero, prints "refcount_t: addition on 0; use-after-free", saturates the counter, and returns the saturated pointer to the caller. Session memory is held live by the in-flight RCU read section, but the kfree_rcu() callback queued from l2tp_session_free() will free it once the grace period closes; a caller that dereferences the returned session past that point hits a slab-use-after-free. On PREEMPT_RT local_bh_disable() is a per-CPU sleeping lock and the preemption window is real; on stock PREEMPT kernels local_bh_disable() is a preempt_count increment that closes the cross-CPU race in practice (see below). Use refcount_inc_not_zero() and continue the list walk on failure, matching the other session getters in the file. The ifname getter is the only session getter in net/l2tp/ that still uses the bare refcount_inc() pattern; this change restores file-internal consistency. The success path is unchanged.

Affected products

Linux
  • <ee80455feffb9cb62b5b58715cabeff495e666b2
  • <947013fd7c8c35dd5856557b215840098a3f67f8
  • ==6.12
  • =<6.18.*
  • <6.12
  • =<7.0.*
  • =<6.12.*
  • <782d60a6596aee9b29c2eecfa70033899278bf65
  • =<*
  • <05f95729ca844704d15e49ce14868af4b403b32b
Dismissed
(max. allowed matches exceeded)
Permalink CVE-2026-63864
8.4 HIGH
  • CVSS version (CVSS): 3.1
  • Attack Vector (AV): Local (L)
  • 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): High (H)
  • Availability (A): High (H)
  • Modified Attack Vector (MAV): Local (L)
  • 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): High (H)
  • Modified Availability (MA): High (H)
created 6 days, 2 hours ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
bpf: Propagate error from visit_tailcall_insn

In the Linux kernel, the following vulnerability has been resolved: bpf: Propagate error from visit_tailcall_insn Commit e40f5a6bf88a ("bpf: correct stack liveness for tail calls") added visit_tailcall_insn() but did not check its return value.

Affected products

Linux
  • <6bd96e40f31dde8f8cd79772b4df0f171cf8a915
  • <945816e63c8677cf4bfde963a0774432ce8afc85
  • =<7.0.*
  • ==6.19
  • =<*
  • <6.19
Dismissed
(max. allowed matches exceeded)
Permalink CVE-2026-63846
7.8 HIGH
  • CVSS version (CVSS): 3.1
  • Attack Vector (AV): Local (L)
  • Attack Complexity (AC): Low (L)
  • Privileges Required (PR): Low (L)
  • User Interaction (UI): None (N)
  • Scope (S): Unchanged (U)
  • Confidentiality (C): High (H)
  • Integrity (I): High (H)
  • Availability (A): High (H)
  • Modified Attack Vector (MAV): Local (L)
  • Modified Attack Complexity (MAC): Low (L)
  • Modified Privileges Required (MPR): Low (L)
  • Modified User Interaction (MUI): None (N)
  • Modified Confidentiality (MC): High (H)
  • Modified Scope (MS): Unchanged (U)
  • Modified Integrity (MI): High (H)
  • Modified Availability (MA): High (H)
created 6 days, 2 hours ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
drm/amdgpu/jpeg: set no_user_fence for JPEG v3.0 ring

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/jpeg: set no_user_fence for JPEG v3.0 ring JPEG rings do not support 64-bit user fence writes, reject CS submissions with user fences. (cherry picked from commit 4d7d774f100efb5089c86a1fb8c5bf47c63fc9ef)

Affected products

Linux
  • <a2baf12eec41f246689e6a3f8619af1200031576
  • =<6.18.*
  • ==5.9
  • =<7.0.*
  • <5ada37d7f736f9feeaa06a25e470a4c74e67a61a
  • =<6.12.*
  • <5.9
  • =<*
  • =<6.6.*
  • <ee035a9d3eed3a9f5a3e83c31a10b321c9598861
  • <48ce00787e3fddd2b45692fc991b8ab128343da5
  • <303da8279f195cc741adc52c1b44d6b64de63bb0
Dismissed
(max. allowed matches exceeded)
Permalink CVE-2026-63824
7.8 HIGH
  • CVSS version (CVSS): 3.1
  • Attack Vector (AV): Local (L)
  • Attack Complexity (AC): Low (L)
  • Privileges Required (PR): Low (L)
  • User Interaction (UI): None (N)
  • Scope (S): Unchanged (U)
  • Confidentiality (C): High (H)
  • Integrity (I): High (H)
  • Availability (A): High (H)
  • Modified Attack Vector (MAV): Local (L)
  • Modified Attack Complexity (MAC): Low (L)
  • Modified Privileges Required (MPR): Low (L)
  • Modified User Interaction (MUI): None (N)
  • Modified Confidentiality (MC): High (H)
  • Modified Scope (MS): Unchanged (U)
  • Modified Integrity (MI): High (H)
  • Modified Availability (MA): High (H)
created 6 days, 2 hours ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
KEYS: fix overflow in keyctl_pkey_params_get_2()

In the Linux kernel, the following vulnerability has been resolved: KEYS: fix overflow in keyctl_pkey_params_get_2() The length for the internal output buffer is calculated incorrectly, which can result overflow when a too small buffer is provided. Fix the bug by allocating internal output with the size of the maximum length of the cryptographic primitive instead of caller provided size.

Affected products

Linux
  • =<5.10.*
  • <670fc6a311ed321522b7fff92cf0fc376b4f6e78
  • <0f3058d7d26f81df9b68a18ddbe164bdc3c5eff3
  • =<6.18.*
  • <5165f1cc727f1322456735df212d8e26ec237a8d
  • <b11c1fa32667692a2c0566e10163758e786e430c
  • <5966e4e2ba213ab7ad559166152eb4f1f170dd2c
  • =<6.12.*
  • =<7.1.*
  • <cb481e59ea6cae3b7796ac1d7a22b6b24c3f3c0b
  • =<6.1.*
  • =<6.6.*
  • ==4.20
  • <622ec2dcd59f21623f2a7ab773c80ceb7d555e3a
  • =<5.15.*
  • =<*
  • <b1e247338bc71826a2d2def3e0874c34749df69a
  • <4.20
Dismissed
(no matching packages found)
Permalink CVE-2026-63769
6.3 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): None (N)
  • 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): High (H)
  • Subsequent System Impact Integrity (SI): None (N)
  • 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): None (N)
  • 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): High (H)
  • Modified Subsequent System Impact Integrity (MSI): Negligible (N)
  • 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 6 days, 2 hours ago Activity log
  • Created & dismissed (no matching packages found) suggestion
Huginn 2022.08.18 SSRF via ScenarioImport fetch_url Method

Huginn through 2022.08.18 contains a server-side request forgery vulnerability in the fetch_url method of ScenarioImport that allows authenticated users to make arbitrary HTTP requests by submitting crafted URLs. Attackers can probe internal network services, enumerate ports via error signatures, and access cloud metadata endpoints to retrieve sensitive credentials.

References

Affected products

huginn
  • =<2022.08.18
Dismissed
(max. allowed matches exceeded)
Permalink CVE-2026-63812
7.8 HIGH
  • CVSS version (CVSS): 3.1
  • Attack Vector (AV): Local (L)
  • Attack Complexity (AC): Low (L)
  • Privileges Required (PR): Low (L)
  • User Interaction (UI): None (N)
  • Scope (S): Unchanged (U)
  • Confidentiality (C): High (H)
  • Integrity (I): High (H)
  • Availability (A): High (H)
  • Modified Attack Vector (MAV): Local (L)
  • Modified Attack Complexity (MAC): Low (L)
  • Modified Privileges Required (MPR): Low (L)
  • Modified User Interaction (MUI): None (N)
  • Modified Confidentiality (MC): High (H)
  • Modified Scope (MS): Unchanged (U)
  • Modified Integrity (MI): High (H)
  • Modified Availability (MA): High (H)
created 6 days, 2 hours ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
f2fs: fix incorrect FI_NO_EXTENT handling in __destroy_extent_node()

In the Linux kernel, the following vulnerability has been resolved: f2fs: fix incorrect FI_NO_EXTENT handling in __destroy_extent_node() When __destroy_extent_node() sets the inode flag FI_NO_EXTENT, it does not reset the length of the largest extent to 0 and update the inode folio. Since modifications to the extent tree are disallowed afterward, the cached largest extent may become stale. This can trigger the following error in xfstests generic/388: F2FS-fs (dm-0): sanity_check_extent_cache: inode (ino=1761) extent info [220057, 57, 6] is incorrect, run fsck to fix In the f2fs_drop_inode path, __destroy_extent_node() does not need to guarantee that et->node_cnt is 0, because concurrency with writeback is expected in this path, and writeback may update the extent cache. This patch reverts commit ed78aeebef05 ("f2fs: fix node_cnt race between extent node destroy and writeback"), and remove the unnecessary zero check of et->node_cnt.

Affected products

Linux
  • <6.12.95
  • <1f70ddb28a3c71df124da5fa4040c808116d6bb9
  • =<6.18.*
  • <6.18.38
  • ==7.1
  • <7.1
  • <7e4d8f98be63f98856a5176b9188dada6e7ba9ee
  • ==0559a0e962aacbb47519e26ee663be04b72dcb92
  • =<6.12.*
  • <20190e498057997532c7f186d081011f18e0a462
  • =<7.1.*
  • =<*
  • =<6.6.*
  • <edf12cbeeeabe799bd2ee21fdb5c336cce6fbad7
  • <7.1
  • <58a5deb220bcac4c73bf58954c0845644c997487
  • <6.6.144
Dismissed
(max. allowed matches exceeded)
Permalink CVE-2026-64106
9.0 CRITICAL
  • CVSS version (CVSS): 3.1
  • Attack Vector (AV): Local (L)
  • Attack Complexity (AC): Low (L)
  • Privileges Required (PR): None (N)
  • User Interaction (UI): None (N)
  • Scope (S): Changed (C)
  • Confidentiality (C): High (H)
  • Integrity (I): None (N)
  • Availability (A): High (H)
  • Modified Attack Vector (MAV): Local (L)
  • 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): Changed (C)
  • Modified Integrity (MI): None (N)
  • Modified Availability (MA): High (H)
created 6 days, 2 hours ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
KVM: arm64: vgic-its: Reject restored DTE with out-of-range num_eventid_bits

In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic-its: Reject restored DTE with out-of-range num_eventid_bits Userspace can restore an ITS Device Table Entry whose Size field encodes more EventID bits than the virtual ITS supports. The live MAPD path rejects that state, but vgic_its_restore_dte() accepts it and stores the out-of-range value in dev->num_eventid_bits. Reject restored DTEs with num_eventid_bits > VITS_TYPER_IDBITS before allocating the device. This mirrors the MAPD check and prevents the restored state from reaching vgic_its_restore_itt(), where the unchecked value can be converted into an oversized scan_its_table() range.

Affected products

Linux
  • <b94538186a3eae3763b8f96dacd610920a865aa7
  • =<6.18.*
  • <0680f511926589206f81f57f76ce131d7741a316
  • =<7.0.*
  • =<6.12.*
  • <9ce754ed8e7ab4e3999767ce1505f85c449ccb07
  • <1716b7fea2ead941a0dfac06c4504a3437cdf00d
  • ==4.12
  • =<6.1.*
  • =<*
  • =<6.6.*
  • <8bcd15b690a390241179516af1b6ae49ebfd9d95
  • <4.12
  • <dab9f93251b2c86a033de6098d0c73afddd55d4a