Nixpkgs security tracker

Try the new UI
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-82213
5.3 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): 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): Low (L)
  • Modified Scope (MS): Unchanged (U)
  • Modified Integrity (MI): None (N)
  • Modified Availability (MA): None (N)
created 1 week, 4 days ago Activity log
  • Created & dismissed (no matching packages found) suggestion
Nexi XPay Build 7.6.1 - 7.6.2 - Unauthenticated Saved Payment Token Disclosure via IDOR

The Nexi XPay Build WordPress plugin from 7.6.1 to 7.6.2 does not verify that the saved payment token being requested belongs to the current user, allowing unauthenticated attackers to retrieve other customers' stored card token references together with a valid authorisation signature.

References

Affected products

Nexi XPay Build
  • =<7.6.2
Dismissed
(no matching packages found)
Permalink CVE-2026-62105
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 1 week, 4 days ago Activity log
  • Created & dismissed (no matching packages found) suggestion
WordPress ThemeREX Addons plugin < 2.45.0 - PHP Object Injection vulnerability

Unauthenticated PHP Object Injection in ThemeREX Addons < 2.45.0 versions.

Affected products

ThemeREX Addons
  • <2.45.0
Dismissed
(max. allowed matches exceeded)
created 1 week, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
eventfs: Initialize ei->children and ei->list in init_ei()

In the Linux kernel, the following vulnerability has been resolved: eventfs: Initialize ei->children and ei->list in init_ei() eventfs_create_dir() allocates the eventfs_inode and initializes it with init_ei(). But this does not initialize the eventfs_inode list_heads. If the eventfs_create_dir() fails due to memory pressure, it will call free_ei() before it initialized the lists, and that checks to make sure the eventfs_inode has no children. But because the list wasn't initialized, it will give a false warning. Fix it by moving the list initialization into init_ei(). [ Rewrote change log ]

Affected products

Linux
  • ==35ee34c0f6d578c9d245438ca29bf2e7024a5a65
  • ==6.7
  • =<*
  • <c480f8af173d5b19c6d9c4311df6bbe352face9e
  • <6.7
  • <76e0f85f650738d768449dbccbc7c55d05f5b609
  • =<7.2.*
  • <5333e18e6b425fcc39c7fea89e3949a2a98bc5e4
  • <6.7
  • =<6.18.*
  • =<6.12.*
  • <1704aaaf5d22bc765c168402350d191e24e245bc
Dismissed
(max. allowed matches exceeded)
created 1 week, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
kho: fix size calculation in kho_preserved_memory_reserve()

In the Linux kernel, the following vulnerability has been resolved: kho: fix size calculation in kho_preserved_memory_reserve() kho_preserved_memory_reserve() calculates the size of a preservation by doing 1 << (order + PAGE_SHIFT). Since the '1' is a 32-bit integer, it can only be shifted by 31. That is, it will only work for preservations up to 2 GiB. Larger preservations will trigger undefined behaviour. While preservations larger than 2 GiB can't be obtained via folios currently, they can be obtained via kho_preserve_pages(). For example, memblock reserve_mem uses kho_preserve_pages(). Reservations larger than 2 GiB are valid and will trigger this bug if properly aligned. Fix it by using 1UL for shifting.

Affected products

Linux
  • <6.16
  • =<7.2.*
  • ==6.16
  • <3a0b8fa2eb36afc88b62a95f33f0c77c71fa5ded
  • <42a6f03cf352eb6e6dbeef95e75e686f4cdb9bd1
  • =<*
Dismissed
(max. allowed matches exceeded)
created 1 week, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
HID: intel-thc-hid: intel-quickspi: validate report size before copy

In the Linux kernel, the following vulnerability has been resolved: HID: intel-thc-hid: intel-quickspi: validate report size before copy write_cmd_to_txdma() builds an output report in qsdev->report_buf, a heap buffer allocated in quickspi_alloc_report_buf() to the device-descriptor derived max_report_len (a few hundred bytes for a touch controller). It copies the caller-supplied report into that buffer: memcpy(write_buf->content, report_buf, report_buf_len); The HID core caps a report at HID_MAX_BUFFER_SIZE (16384) by default, and quickspi_hid_ll_driver does not set max_buffer_size, so the length reaches the driver unbounded. A hidraw SET_REPORT/SET_FEATURE ioctl carrying a report larger than max_report_len therefore overflows report_buf with attacker-controlled length and content. Record the report_buf allocation size and reject reports that do not fit before copying, matching the equivalent guard in the intel-quicki2c sibling (quicki2c_init_write_buf()) and the hid-goodix-spi fix. write_cmd_to_txdma() writes the output report header ahead of the content in the same buffer, so size the allocation to cover the header as well. That keeps the added bound from rejecting a maximum-sized report.

Affected products

Linux
  • =<7.2.*
  • ==6.14
  • <6fcefe71aeb524f6e77fe586fe85d873745e917c
  • <ee8ad1bb1e96164d51089b1182f1bd5f187e7baa
  • =<6.18.*
  • <6.14
  • <a59cf84441f9a17323c89452cec2bf16724c48a9
  • =<*
Dismissed
(no matching packages found)
Permalink CVE-2026-89298
4.9 MEDIUM
  • CVSS version (CVSS): 3.1
  • Attack Vector (AV): Network (N)
  • Attack Complexity (AC): Low (L)
  • Privileges Required (PR): High (H)
  • 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): High (H)
  • 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 1 week, 4 days ago Activity log
  • Created & dismissed (no matching packages found) suggestion
Keycloak-services: keycloak-services: confidential client secret disclosed to view-clients role via client registration get

A flaw was found in the Dynamic Client Registration service of Keycloak, an open-source identity and access management solution. The issue occurs when a user with the view-clients role accesses the client registration endpoint to retrieve client details. Due to a failure to mask sensitive information, the service returns the client's confidential secret in cleartext. This could allow a read-only administrator to obtain full access to the affected client's account and potentially escalate their privileges within the realm.

References

Affected products

keycloak-services
rhbk/keycloak-rhel9
keycloak/rhbk-openshift-rhel9
Dismissed
(max. allowed matches exceeded)
created 1 week, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
ACPI: APEI: GHES: fix ARM section length accounting after header

In the Linux kernel, the following vulnerability has been resolved: ACPI: APEI: GHES: fix ARM section length accounting after header In ghes_handle_arm_hw_error(), after skipping the cper_sec_proc_arm header with (err + 1), the remaining length was reduced by sizeof(err) (pointer size) instead of sizeof(*err) (structure size). That overestimates the bytes left for cper_arm_err_info records and can let the parser read past the CPER section when err_info_num is large enough relative to error_data_length. Use sizeof(*err) so the length accounting matches the pointer advance and the earlier sizeof(*err) size check.

Affected products

Linux
  • <b48b613073c3d652cb1823c15d16f7067cf4cee4
  • <903308ea40adf0577d82eab69882faf8836326ce
  • <6.12.109
  • =<7.2.*
  • <452eb28e03015abec6d4bf6488ee567706ade4e1
  • <5ff385e9403e87ae33f65b8c38698d3b1e92cfde
  • ==db103b8bd3a4aca69b1b5fe8831a6ed75ac4b3bd
  • <6.20
  • <6.18.50
  • ==7.0
  • =<6.18.*
  • <7.0
  • =<6.12.*
  • =<*
Dismissed
(max. allowed matches exceeded)
created 1 week, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
nfsd: fix null dereference in nfsd4_setattr for deleg timestamp attrs

In the Linux kernel, the following vulnerability has been resolved: nfsd: fix null dereference in nfsd4_setattr for deleg timestamp attrs When a SETATTR request includes FATTR4_WORD2_TIME_DELEG_ACCESS or FATTR4_WORD2_TIME_DELEG_MODIFY in the attribute bitmap, nfsd4_setattr() sets deleg_attrs=true and calls nfs4_preprocess_stateid_op() to validate the stateid. If the client supplies the NFSv4 "one stateid" (all-0xFF bytes), check_special_stateids() returns nfs_ok without populating the output nfs4_stid pointer, because the special-stateid path in nfs4_preprocess_stateid_op() jumps to done: with s==NULL, and the "if (s)" block that would set *cstid is skipped. The local variable `st` remains NULL. Back in nfsd4_setattr(), the if (deleg_attrs) block then unconditionally dereferences st->sc_type (at offset 4 from NULL), causing a kernel oops. This is remotely triggerable by any NFSv4 client: send COMPOUND [PUTROOTFH, SETATTR(ONE_STATEID, {bmval2=FATTR4_WORD2_TIME_DELEG_ACCESS, ...})]. No authentication, delegation, or prior state is required. Fix by adding a NULL check before the dereference. A special stateid is not a delegation stateid, so the existing nfserr_bad_stateid return value is already correct; we only need to guard the pointer dereference itself.

Affected products

Linux
  • <3c5119b799a7f57db332b2c31e806de16c869f0f
  • <fe456c8c0931bb3e8a03d429920e87fd85747fba
  • =<7.2.*
  • ==6.14
  • =<6.18.*
  • <6.14
  • =<*
  • <3c896db123892256fd39af0ee8c2d02c63539983
Dismissed
(max. allowed matches exceeded)
created 1 week, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
mm/vmscan: report RCU-tasks quiescent states in shrink_lruvec()

In the Linux kernel, the following vulnerability has been resolved: mm/vmscan: report RCU-tasks quiescent states in shrink_lruvec() I am seeing some rcu_tasks stalls in the Meta fleet during reclaim. INFO: rcu_tasks detected stalls on tasks: 0000000088620d09: .. nvcsw: 6735/6735 holdout: 1 idle_cpu: -1/8 task:GlobalCPUThread state:R running task pid:2552016 tgid:2524552 Call Trace: shrink_lruvec mem_cgroup_iter shrink_node do_try_to_free_pages try_to_free_pages __alloc_frozen_pages_noprof alloc_pages_noprof pte_alloc_one __pte_alloc handle_mm_fault Nothing promises direct reclaim returns in bounded time, and the scan loop in shrink_lruvec() only calls cond_resched(), which is a no-op on PREEMPTION kernels. Involuntary preemption is not a Tasks-RCU quiescent state, so the reclaiming task never reports one and becomes a holdout. Upgrade it to cond_resched_tasks_rcu_qs(), which reports a quiescent state even when cond_resched() does nothing. PS: This has been discussed in [1]

Affected products

Linux
  • <7.2.4
  • <6.12.109
  • =<7.2.*
  • <cf3ba0911a1cf8680371ff113b90088edd01d2bb
  • =<6.12.*
  • =<6.18.*
  • <b5391676c61d94ffe3272dcf6723738b802f79e8
  • <3fd50239986302cb050d3649351bcec00fa9d5ab
  • <25f52e81216884a7444bf07a606691feb09a94e3
  • <6.18.50
  • =<*
Dismissed
(max. allowed matches exceeded)
created 1 week, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
tpm: tpm_i2c_nuvoton: disable IRQ on wait timeout

In the Linux kernel, the following vulnerability has been resolved: tpm: tpm_i2c_nuvoton: disable IRQ on wait timeout i2c_nuvoton_wait_for_stat() enables the IRQ before waiting for the interrupt handler to report a status change. If the wait times out, or is interrupted before the handler runs, the function returns without balancing the enable_irq() call. Disable the IRQ before leaving the failed wait path. Also preserve an interrupted wait's original error code instead of converting it to -ETIMEDOUT inside the helper.

Affected products

Linux
  • <cde2d927c29e82380851f209222256c607969a1f
  • <3.13
  • =<7.2.*
  • <705c4ed0643366963547b2616d53165f2519c81f
  • <aee2296d09f6aeff41db369c6fd2dcaea3ee302c
  • =<6.18.*
  • ==3.13
  • <73e89faee1f9b9119fa70b679058b045168ae633
  • =<6.12.*
  • =<*