CVE-2026-43026

What it actually does

This is a Linux kernel netfilter/conntrack flaw in expectation handling. When a userspace ctnetlink message creates a conntrack expectation without the CTA_EXPECT_NAT attribute, the kernel allocates the expectation object from a slab cache that is not zero-initialized and fails to clear NAT-related fields. Later, when expectations are dumped back to userspace, stale values left by a prior allocation can be interpreted as valid NAT metadata and returned in the netlink response. The practical impact is local exposure of stale kernel object data associated with previous netfilter expectation allocations. Exploitation requires local access with sufficient privilege to interact with conntrack/netfilter netlink interfaces, typically CAP_NET_ADMIN in the relevant network namespace. No public exploit maturity is reported, EPSS is very low and flat, and it is not listed in KEV.

Why it matters to the business

Organizations running affected Linux kernels may have a local information disclosure risk where users or contained workloads with network-administration capabilities can read stale netfilter expectation data that should have been cleared. The most likely consequence is leakage of prior NAT/connection-tracking metadata, which could reveal internal addressing or traffic-handling details and assist further local or lateral activity. Because exploitation is local and privileged, broad internet-scale exploitation is unlikely; however, the issue matters more on multi-tenant Linux systems, container platforms, systems allowing untrusted workloads with CAP_NET_ADMIN, and environments heavily using conntrack helpers, NAT, or advanced firewalling.

How an attack unfolds

An attacker first obtains local execution on a Linux system and gains the ability to send netfilter conntrack netlink messages, usually through CAP_NET_ADMIN in a network namespace. They then create and delete conntrack expectations that include NAT attributes to populate the relevant kernel slab cache with NAT-bearing expectation objects. After freeing those objects, they create a new expectation without providing CTA_EXPECT_NAT. Because the vulnerable kernel path does not zero the NAT-related fields, the new expectation may retain stale saved_addr, saved_proto, and direction values from a prior slab occupant. The attacker then requests a ctnetlink dump of expectations. The dump routine sees the stale fields and emits a spurious CTA_EXPECT_NAT attribute, leaking stale metadata back to userspace. Repeating the sequence may allow the attacker to sample additional stale netfilter expectation data, depending on system activity and allocator reuse.

How to fix it

Apply the Linux kernel update from the operating system or appliance vendor that includes the netfilter ctnetlink fix to zero saved_addr, saved_proto, and dir when CTA_EXPECT_NAT is absent. Because no exact fixed package versions were provided, use the fixed kernel versions published by the relevant distribution or kernel supplier and reboot into the updated kernel. As interim risk reduction, restrict CAP_NET_ADMIN and other network-administration capabilities from untrusted users and containers, disable unneeded conntrack helper/expectation functionality, avoid exposing privileged network namespaces to untrusted workloads, and unload or avoid nf_conntrack_netlink where it is not operationally required. Container and Kubernetes environments should review security contexts and avoid granting NET_ADMIN except where strictly necessary.

How to confirm the fix worked

Confirm remediation by verifying the running kernel version matches a vendor advisory or package version that includes the ctnetlink expectation NAT-field zeroing fix. Do not rely only on installed package state; confirm the active booted kernel after reboot. Validate exposure by checking whether the system has netfilter conntrack expectation support and NAT enabled, whether nf_conntrack_netlink is loaded or available, and whether untrusted accounts, services, or containers have CAP_NET_ADMIN. A functional validation can be performed in a controlled test environment by attempting to create expectations without CTA_EXPECT_NAT after priming NAT-bearing expectations and confirming expectation dumps no longer emit unexpected CTA_EXPECT_NAT attributes. Production validation should prioritize version/configuration checks over exploit-style testing.

Typical attack path

1. Gain local code execution on an affected Linux host or inside a container/network namespace.
2. Obtain permission to manage conntrack/netfilter state, typically CAP_NET_ADMIN in the applicable network namespace.
3. Ensure conntrack expectation and NAT functionality are available and loaded, such as nf_conntrack, nf_conntrack_netlink, and NAT support.
4. Prime the conntrack expectation slab by creating NAT-bearing expectations.
5. Delete or allow those expectations to be freed so their slab memory can be reused.
6. Create a new conntrack expectation through ctnetlink without the CTA_EXPECT_NAT attribute.
7. Dump conntrack expectations from userspace and inspect the returned netlink attributes.
8. Extract any unexpected CTA_EXPECT_NAT data that reflects stale fields from the previous allocation.

How to detect it

There are no reliable, unique host or network indicators that prove exploitation, because the activity uses legitimate netfilter/conntrack netlink interfaces and may not be logged by default. To investigate possible prior exploitation, review audit logs and endpoint telemetry for unexpected processes opening NETLINK_NETFILTER sockets or invoking conntrack tooling, especially processes running in containers or under accounts that should not manage firewall state. Check shell history, process accounting, EDR telemetry, and container runtime logs for use of conntrack expectation commands or custom binaries interacting with ctnetlink. Review capability assignments for workloads that had CAP_NET_ADMIN before remediation. If auditd was configured to record capability use or execution of conntrack utilities, look for unusual execution timing, repeated expectation creation/deletion, or expectation dumps. Also inspect current conntrack expectations with administrative tooling for unexpected helper/NAT expectation entries, while recognizing that exploitation can complete without leaving persistent expectation state.

What your security team should do

• Prioritize patching Linux hosts that run containers, multi-tenant workloads, untrusted local users, firewalls, gateways, NAT infrastructure, or workloads granted CAP_NET_ADMIN.
• Inventory systems with nf_conntrack, nf_conntrack_netlink, NAT, and conntrack helper/expectation functionality enabled.
• Remove CAP_NET_ADMIN from containers and services that do not explicitly require it; review Kubernetes securityContext capabilities and privileged containers.
• Reboot after kernel updates and verify the active running kernel is the fixed version, not just that packages are installed.
• Restrict local shell access and administrative container access on systems that cannot be patched immediately.
• Monitor for unusual conntrack expectation manipulation, especially by non-administrative processes or unexpected container workloads.
• Treat the issue as lower internet-exploitation urgency due to local privileged prerequisites and low EPSS, but do not ignore it on shared or containerized Linux platforms.