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
(max. allowed matches exceeded)
Permalink CVE-2026-64046
9.8 CRITICAL
  • 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): High (H)
  • Availability (A): High (H)
  • 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): High (H)
  • Modified Availability (MA): High (H)
created 6 days, 7 hours ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
net: tls: prevent chain-after-chain in plain text SG

In the Linux kernel, the following vulnerability has been resolved: net: tls: prevent chain-after-chain in plain text SG Sashiko points out that if end = 0 (start != 0) the current code will create a chain link to content type right after the wrap link: This would create a chain where the wrap link points directly to another chain link. The scatterlist API sg_next iterator does not recursively resolve consecutive chain links. meaning this is illegal input to crypto. The wrapping link is unnecessary if end = 0. end is the entry after the last one used so end = 0 means there's nothing pushed after the wrap: end start i v v v [ ]...[ ][ d ][ d ][ d ][ d ][rsv for wrap] Skip the wrapping in this case. TLS 1.3 can use the "wrapping slot" for it's chaining if end = 0. This avoids the chain-after-chain. Move the wrap chaining before marking END and chaining off content type, that feels like more logical ordering to me, but should not matter from functional perspective.

Affected products

Linux
  • =<6.1.*
  • =<5.15.*
  • =<5.10.*
  • =<7.0.*
  • <acdc12b71c9aa4be5dcd2c8062753c6d2033e235
  • <929b1548e63ac72e104c07d8ee8cbbeeba2fa89a
  • <410351158dfef2d67fea6603680b3a6013c6ed9d
  • <49a5faaa471ddcd37b6893970c9916eb836e7c31
  • <5.5
  • =<6.6.*
  • <5.5
  • <ff26a0e8377dec07e4a7230db7675bed1b9a6d03
  • ==d529d6c9f7e3aaeac13c4948f79799ccb825f29d
  • ==5.5
  • <91359966e247c0244c66d50bbb8e74aefa4321c3
  • =<6.18.*
  • <af855f4c966afafef74faf8390c7b86568c0d46d
  • =<6.12.*
  • =<*
  • <b9c015ef1a7bf1e8dc67f21c6381f36deb2c3a36
Dismissed
(max. allowed matches exceeded)
Permalink CVE-2026-63992
9.1 CRITICAL
  • 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): High (H)
  • 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): High (H)
created 6 days, 7 hours ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
tunnels: do not assume transport header in iptunnel_pmtud_check_icmp()

In the Linux kernel, the following vulnerability has been resolved: tunnels: do not assume transport header in iptunnel_pmtud_check_icmp() In some cases, iptunnel_pmtud_check_icmp() can be called while skb transport header is not set. This triggers an out-of-bound access, because (typeof(skb->transport_header))~0U is 65535. Access the icmp header based on IPv4 network header, after making sure icmp->type is present in skb linear part. Note that iptunnel_pmtud_check_icmpv6()) is fine.

Affected products

Linux
  • <a096b6e34f602950af9a2b0856cd93a5f4c276d7
  • <5a92cb45e34749865d03daf8d3500f77b5f6644c
  • =<6.18.*
  • <cb549df9ce4ee15c9d5b19ddab12cf2128e4313c
  • =<7.0.*
  • <7f4f7efe7f30edd29c4988de01728bf2398217e4
  • =<5.15.*
  • =<6.12.*
  • <5.9
  • =<6.1.*
  • =<*
  • <43368636c663cff6e59dde93cf4b8e43ac28eb93
  • =<6.6.*
  • ==5.9
  • <e917d0c69f01af2bb4fbea2b66d560a53b3ac7ec
  • <c7b7ec3e69e673c0d6b57f74d21da50c485c598e
  • <509323077ef79a26ba0c60bb556e45c12c398b2d
  • =<5.10.*
Dismissed
(max. allowed matches exceeded)
created 6 days, 7 hours ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
usb: typec: tcpm: bound altmode_desc[] per iteration in svdm_consume_modes()

In the Linux kernel, the following vulnerability has been resolved: usb: typec: tcpm: bound altmode_desc[] per iteration in svdm_consume_modes() svdm_consume_modes() checks pmdata->altmodes against the array size once before the loop over the count, but forgot to check the bound at every point in the loop. In the well-behaved SVDM discovery flow this is harmless because each of at most SVID_DISCOVERY_MAX SVIDs contributes at most MODE_DISCOVERY_MAX modes, exactly filling altmode_desc[ALTMODE_DISCOVERY_MAX]. But the CMDT_RSP_ACK handler in tcpm_pd_svdm() does not correlate an incoming ACK with any request the port actually sent. Once port->partner is set, an unsolicited Discover Modes ACK is consumed unconditionally. A broken or malicious port partner can therefore drive altmodes to ALTMODE_DISCOVERY_MAX - 1 via the normal flow, and then send one extra Discover Modes ACK with seven VDOs. Because the pre-loop check passes, the loop could then writes up to five entries past altmode_desc[]. For mode_data_prime the next field in struct tcpm_port is the partner_altmode[] pointer array, which then receives partner-chosen SVID/VDO bytes. Move the bound check inside the loop so the array can never be indexed past ALTMODE_DISCOVERY_MAX regardless of how many VDOs the partner supplies or how the function was reached.

Affected products

Linux
  • <845598b154b9a92e9d279fafafa9405c121ae805
  • =<6.18.*
  • <4.19
  • =<7.0.*
  • =<6.12.*
  • <3389c149c68c3fea61910ad5d34f7bf3bff44e32
  • =<*
  • <cbad85b446c06adbc5e5bed565871bb918ce9d32
  • <4505f33dab56c274e82f47f94bf60a8cbf8f4b42
  • ==4.19
Dismissed
(max. allowed matches exceeded)
Permalink CVE-2026-63857
9.8 CRITICAL
  • 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): High (H)
  • Availability (A): High (H)
  • 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): High (H)
  • Modified Availability (MA): High (H)
created 6 days, 7 hours ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
net: airoha: Do not read uninitialized fragment address in airoha_dev_xmit()

In the Linux kernel, the following vulnerability has been resolved: net: airoha: Do not read uninitialized fragment address in airoha_dev_xmit() The transmit loop in airoha_dev_xmit() reads fragment address and length during its final iteration, when the loop index equals skb_shinfo(skb)->nr_frags, at which point the fragment data is uninitialized. While these values are never consumed, the read itself is unsafe and may trigger a page fault. Fix this by avoiding the fragment read on the last iteration. Additionally, move the skb pointer from the first to the last used packet descriptor, so that airoha_qdma_tx_napi_poll() defers freeing the skb until the final descriptor is processed.

Affected products

Linux
  • <d78c8ab7bd84952e053d0c622b7fc1b4ad8a19a3
  • =<6.18.*
  • =<7.0.*
  • <f670fa4b19ceddc6d215dda4997888ccba9bbc61
  • <6.11
  • =<*
  • <bde34e84edc8b5571fbde7e941e175a4293ee1eb
  • ==6.11
Dismissed
(max. allowed matches exceeded)
Permalink CVE-2026-53398
9.8 CRITICAL
  • 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): High (H)
  • Availability (A): High (H)
  • 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): High (H)
  • Modified Availability (MA): High (H)
created 6 days, 7 hours ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
NFSD: Fix SECINFO_NO_NAME decode error cleanup

In the Linux kernel, the following vulnerability has been resolved: NFSD: Fix SECINFO_NO_NAME decode error cleanup nfsd4_decode_secinfo_no_name() currently initializes sin_exp after decoding sin_style. If the XDR stream is truncated, the decoder returns nfserr_bad_xdr before sin_exp is initialized. Since commit 3fdc54646234 ("NFSD: Reduce amount of struct nfsd4_compoundargs that needs clearing"), the inline iops array is not cleared between RPC calls. A failed SECINFO_NO_NAME decode can therefore leave sin_exp holding stale union contents from a previous operation. The error response path still invokes nfsd4_secinfo_no_name_release(), which calls exp_put() on a non-NULL sin_exp. Initialize sin_exp before the first failable decode step, matching nfsd4_decode_secinfo().

Affected products

Linux
  • <8836405abdc53ca3dd5fc68b2cf6f8f012fad011
  • <5ec37edcb534f3fc92304be236d37f08e6545585
  • =<7.1.*
  • =<6.1.*
  • =<5.15.*
  • =<5.10.*
  • <161d1aaeb04d620d3692639700512bb5038c1e10
  • <5.15.211
  • <6.1
  • <9e18e83b8846a5c3fe13fc8a464b4865d33996c6
  • <c8a24effd96d4779e2ad779654682304491c55a5
  • <5.10.260
  • ==6.1
  • <1e04be34cafae119e82bcaccd6d28a20f72a3647
  • <49de5d31dd8fdebf78bdeaf196b0ca5cd5c75439
  • =<6.6.*
  • <46eb17d45be69d28c7a23ea03283b207426a8232
  • =<6.18.*
  • =<6.12.*
  • =<*
Dismissed
(no matching packages found)
created 6 days, 7 hours ago Activity log
  • Created & dismissed (no matching packages found) suggestion
Apache Syncope: Remote Code Execution via Scripted Connector

Improper Isolation or Compartmentalization vulnerability in Apache Syncope. An administrator with adequate entitlements can achieve remote code execution through the connector subsystem by relying on scripted connectors' (REST and SQL) capability to run Groovy scripts. This issue affects Apache Syncope: from 3.0.0-M0 through 3.0.16, from 4.0.0-M0 Through 4.0.6, from 4.1.0-M0 through 4.1.1. Users are recommended to upgrade to version 4.0.7 / 4.1.2, which fix this issue by hardening the Groovy security sandbox.

Affected products

Apache Syncope
  • =<4.1.1
  • =<4.0.6
  • =<3.0.16
Dismissed
(max. allowed matches exceeded)
Permalink CVE-2026-64058
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, 7 hours ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
netfs: Fix netfs_read_folio() to wait on writeback

In the Linux kernel, the following vulnerability has been resolved: netfs: Fix netfs_read_folio() to wait on writeback Fix netfs_read_folio() to wait for an ongoing writeback to complete so that it can trust the dirty flag and whatever is attached to folio->private (folio->private may get cleaned up by the collector before it clears the writeback flag).

Affected products

Linux
  • ==6.12
  • =<6.18.*
  • <b8271cccdd5e43cc8d738afb8b51f6ad05b1cb4b
  • <6.12
  • =<7.0.*
  • <ded0c6f1606061148c202825f7e53d711f9f84cf
  • <f17b9121bb99f88188ec9be2db5da1d561f4c01b
  • =<*
Dismissed
(no matching packages found)
Permalink CVE-2026-12973
6.5 MEDIUM
  • 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): Low (L)
  • Integrity (I): Low (L)
  • 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): Low (L)
  • Modified Scope (MS): Unchanged (U)
  • Modified Integrity (MI): Low (L)
  • Modified Availability (MA): None (N)
created 6 days, 7 hours ago Activity log
  • Created & dismissed (no matching packages found) suggestion
PayPlus Payment Gateway < 8.2.2 - Unauthenticated Order Key Disclosure and Order Status Modification

The PayPlus Payment Gateway WordPress plugin before 8.2.2 does not perform authorization or order-ownership validation in one of its AJAX actions available to unauthenticated users, allowing them to disclose the secret order key of arbitrary WooCommerce orders and, under some configurations, to modify order statuses.

References

Affected products

PayPlus Payment Gateway
  • <8.2.2
Dismissed
(no matching packages found)
Permalink CVE-2026-51026
6.5 MEDIUM
  • CVSS version (CVSS): 3.1
  • Attack Complexity (AC): Low (L)
  • Attack Vector (AV): Network (N)
  • Availability (A): None (N)
  • Confidentiality (C): High (H)
  • Integrity (I): None (N)
  • Privileges Required (PR): Low (L)
  • Scope (S): Unchanged (U)
  • User Interaction (UI): 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): High (H)
  • Modified Scope (MS): Unchanged (U)
  • Modified Integrity (MI): None (N)
  • Modified Availability (MA): None (N)
created 6 days, 7 hours ago Activity log
  • Created & dismissed (no matching packages found) suggestion
Directory Traversal vulnerability in FileThingie v.2.5.7 allows a remote attacker …

Directory Traversal vulnerability in FileThingie v.2.5.7 allows a remote attacker to obtain sensitive information via a crafted request.

Affected products

n/a
  • ==n/a
Dismissed
(max. allowed matches exceeded)
Permalink CVE-2026-64016
9.8 CRITICAL
  • 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): High (H)
  • Availability (A): High (H)
  • 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): High (H)
  • Modified Availability (MA): High (H)
created 6 days, 7 hours ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
ksmbd: fix durable reconnect error path file lifetime

In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix durable reconnect error path file lifetime After a durable reconnect succeeds, ksmbd_reopen_durable_fd() republishes the same ksmbd_file into the session volatile-id table. If smb2_open() then takes a later error path, cleanup first calls ksmbd_fd_put(work, fp) and then unconditionally calls ksmbd_put_durable_fd(dh_info.fp). In this case fp and dh_info.fp are the same object. The first put drops the reconnect lookup reference, but the final durable put can run __ksmbd_close_fd(NULL, fp). Because the final close is not session-aware, it can free the file object without removing the volatile-id entry that was just published into the session table. Use the session-aware put for the final reconnect drop when the reconnect had already succeeded and the error path is cleaning up the republished file. Earlier reconnect failures, before fp is assigned to dh_info.fp, keep using the durable-only put path.

Affected products

Linux
  • <a1a39f227c80cbf369767badc32cba2b225147d1
  • <3515503322f4819277091839eed46b695096aca5
  • <6.18.34
  • <7.0.11
  • <6cb0b9385320110fe24a5d5ac0000ade4bb3a3f3