CVE-2026-43060

What it actually does

This is a Linux kernel netfilter/nftables use-after-free condition in the conntrack integration path. Packets held in NFQUEUE can retain references to conntrack-related objects such as templates, conntrack zones, timeout policies, and helpers. If those objects are removed while packets remain queued, later packet handling can dereference stale kernel memory. A successful exploit could corrupt kernel memory, crash the host, or potentially execute code with kernel privileges. Exploitation is local and requires low privileges in the CVSS model, but in practice usually depends on the attacker having, obtaining, or abusing CAP_NET_ADMIN, nftables control, or network namespace capabilities.

Why it matters to the business

The main risk is privilege escalation or host compromise on Linux systems where untrusted users, containers, or services can manipulate nftables/netfilter state. A successful attack could let an attacker take control of the operating system, bypass isolation boundaries, tamper with traffic filtering, or cause outages through kernel crashes. The current public exploitation signal is low: EPSS is 0.0012, unchanged over 30 days, the issue is not listed in CISA KEV, is not known to be used in ransomware campaigns, and has no reported public exploit maturity; however, kernel local privilege-escalation bugs remain important on shared, containerized, and internet-facing infrastructure.

How an attack unfolds

An attacker first needs local execution on a Linux system and a path to influence netfilter/nftables behavior, commonly through CAP_NET_ADMIN, a privileged container, a misconfigured user namespace, or a service that exposes firewall-management functionality. The attacker creates nftables rules that use conntrack features and queues matching packets into NFQUEUE so those packets remain pending in userspace. While packets are still enqueued, the attacker removes or unloads related conntrack objects such as templates, timeout policies, helpers, or module-backed state. Because queued packets can still hold references to objects that have been freed, subsequent processing or reinjection of those packets can trigger a use-after-free in kernel context. With careful heap shaping this may be used for privilege escalation or kernel code execution; less controlled attempts are likely to produce denial of service through a kernel oops or panic.

How to fix it

Apply a vendor kernel update that includes the upstream fix for netfilter nft_ct handling of queued packets on object removal, specifically the change that drops pending enqueued packets when dependent conntrack objects are removed. Because no product-specific fixed versions were provided, use the fixed kernel versions published by the relevant Linux distribution or kernel vendor. Where immediate patching is not possible, reduce exposure by restricting CAP_NET_ADMIN, avoiding privileged containers, disabling unneeded unprivileged user namespaces where operationally feasible, limiting who can run nft/iptables/firewall-management tooling, and removing unnecessary conntrack helper or NFQUEUE usage. Do not rely on mitigation alone for long-term risk reduction; kernel update and reboot into the fixed kernel are the durable remediation.

How to confirm the fix worked

Confirm that systems are booted into a kernel build containing the netfilter fix, not merely that an updated kernel package is installed. Validate with vendor advisory metadata, package changelogs, kernel build notes, or source backport references for the fix titled "netfilter: nft_ct: drop pending enqueued packets on removal." Check running kernel versions with standard platform inventory and compare them against distribution-fixed releases. Review whether NFQUEUE, nftables conntrack rules, conntrack helpers, or conntrack timeout policies are in use, since those features define practical exposure. After patching, reboot where required, verify the active kernel version, and confirm no vulnerable kernel remains selected as the default boot target.

Typical attack path

1. Gain local code execution on a Linux host, container, or namespace with access to nftables/netfilter administration capabilities.
2. Create nftables rules using conntrack-related features and configure matching traffic to be sent to NFQUEUE.
3. Generate or capture packets that match the rules and remain pending in the NFQUEUE userspace path.
4. Remove nftables, conntrack helper, conntrack timeout, zone/template, or related module-backed objects while packets are still queued.
5. Trigger packet reinjection, verdict handling, timeout, or cleanup so the kernel processes stale references held by queued packets.
6. Exploit the resulting use-after-free for kernel memory corruption, privilege escalation, or denial of service.

How to detect it

Historical exploitation is difficult to prove because successful use-after-free exploitation may leave few durable artifacts beyond kernel crash, audit, and command-execution evidence. Review kernel logs, crash dumps, pstore/ramoops, journald, auditd, EDR telemetry, and shell/process history for suspicious sequencing: nftables or conntrack rule creation, NFQUEUE use, removal of conntrack helpers/timeouts/templates, module unload activity, and then kernel oops, panic, KASAN, or memory-corruption messages. Pay particular attention to nft, iptables-nft, conntrack, modprobe, rmmod, and custom NFQUEUE daemons executed by accounts or containers that do not normally administer host firewall policy. On systems with auditd, search for CAP_NET_ADMIN use, namespace creation, and execution of firewall-management binaries. In container environments, correlate privileged container starts or user-namespace activity with host-level netfilter changes. The absence of these artifacts does not rule out exploitation, especially if logs were rotated or the host crashed before persistence was written.

• BUG: KASAN: use-after-free
• use-after-free in nft_ct
• nft_ct
• nfqueue
• NFQUEUE
• nfnetlink_queue
• nf_conntrack_helper
• nf_conntrack_timeout
• comm="nft"
• comm="iptables-nft"
• comm="conntrack"
• comm="modprobe"
• comm="rmmod"
• CAP_NET_ADMIN
• queue num
• ct helper
• ct timeout
• kernel panic - not syncing
• Oops:
• general protection fault

What your security team should do

• Prioritize patching shared Linux hosts, container hosts, Kubernetes nodes, bastion systems, CI runners, VPN gateways, firewalls, and any system where untrusted users or workloads may obtain network namespace or CAP_NET_ADMIN capabilities.
• Inventory systems using nftables, NFQUEUE, conntrack helpers, or custom firewall orchestration and schedule kernel updates followed by reboots into fixed kernels.
• Restrict CAP_NET_ADMIN and privileged-container usage; audit container runtime, orchestration, and user namespace settings that may allow untrusted workloads to manipulate netfilter state.
• Monitor for suspicious nft, iptables, conntrack, modprobe, or NFQUEUE activity by non-administrative accounts, especially followed by kernel oops, panic, or KASAN use-after-free messages.
• Because EPSS is low and there is no KEV or known ransomware use, prioritize based on exposure and privilege boundaries rather than broad emergency treatment, but do not defer patching on multi-tenant or containerized systems.