CVE-2026-46244

What it actually does

CVE-2026-46244 is a Linux kernel netfilter flaw in nftables inner-packet parsing for IPv6 traffic. When nft_inner_parse_l2l3() parses an encapsulated IPv6 packet, ipv6_find_hdr() correctly walks IPv6 extension headers to locate the real transport header, but the computed offset is overwritten with a fixed 40-byte IPv6 base-header offset. As a result, netfilter can believe the inner packet is using one Layer 4 protocol while matching transport-layer fields at the wrong offset. An attacker can craft encapsulated IPv6 packets with extension headers so nftables inner-header rules evaluate forged or attacker-controlled bytes instead of the actual TCP, UDP, or other transport header. The practical result is potential firewall or policy bypass where nftables rules rely on inner IPv6 transport-header matching.

Why it matters to the business

Organizations using Linux systems as firewalls, routers, gateways, container hosts, overlay-network nodes, or packet-filtering enforcement points may have traffic controls that can be bypassed for certain encapsulated IPv6 flows. This can allow prohibited traffic to reach protected services, undermine segmentation policies, and weaken controls used for tenant isolation, workload isolation, or perimeter filtering. The CVSS score is high because exploitation is network-reachable, requires no authentication, and can affect confidentiality and integrity by allowing traffic that policy intended to block. EPSS is currently low and the issue is not listed in CISA KEV, which suggests no confirmed broad exploitation at this time, but exposure should still be prioritized anywhere nftables inner-packet matching is used for security enforcement.

How an attack unfolds

An attacker first identifies a path where a Linux kernel using nftables processes encapsulated or tunneled IPv6 traffic with rules that inspect inner packet headers. The attacker then crafts an inner IPv6 packet containing one or more extension headers before the real transport header. Because the vulnerable kernel overwrites the correct transport-header offset with the fixed IPv6 base-header offset, nftables may inspect bytes at the beginning of an extension header while still treating the packet as if it had the transport protocol discovered later in the packet. The attacker places chosen values in the extension-header area so firewall rules appear to match an allowed TCP or UDP port, state, or header field, while the actual transport header contains different values. If policy decisions depend on those inner-header matches, the packet can be accepted, routed, or forwarded contrary to the intended rules.

How to fix it

Upgrade the Linux kernel to a vendor-provided release that includes the netfilter nft_inner IPv6 inner_thoff fix. Because no specific fixed versions were provided in the input, use the relevant Linux distribution security advisory or upstream stable kernel changelog to identify the patched kernel for each platform. Prioritize systems that act as firewalls, routers, VPN concentrators, Kubernetes/container hosts, overlay-network nodes, or any hosts using nftables rules with inner-packet inspection. If immediate patching is not possible, reduce exposure by disabling or avoiding nftables rules that rely on inner IPv6 transport-header matching, blocking unnecessary tunneled or encapsulated IPv6 traffic at earlier enforcement points, and applying conservative default-deny rules for affected paths. Where operationally feasible, normalize or drop IPv6 packets with unexpected extension-header chains before they reach vulnerable nftables inner-header policy logic.

How to confirm the fix worked

Confirm the running kernel includes the vendor patch for the nft_inner IPv6 transport-header offset bug, not merely that an updated package is installed. Validate with the active kernel version after reboot and compare it against the distribution advisory or upstream stable release containing the fix. Review nftables configurations for use of inner-packet matching, especially rules that inspect inner IPv6 protocol or transport fields. Where a safe test environment is available, reproduce policy behavior with encapsulated IPv6 packets containing extension headers and verify that rules no longer accept traffic based on forged bytes at the extension-header offset. Also confirm that compensating controls, such as blocking unnecessary encapsulated IPv6 traffic, remain in place until all affected kernels are remediated.

Typical attack path

1. Find a Linux-based filtering point that uses nftables/netfilter and processes encapsulated IPv6 traffic.
2. Determine or infer that nftables rules inspect inner IPv6 transport fields, such as protocol or port, for access-control decisions.
3. Craft encapsulated IPv6 packets containing extension headers before the actual TCP, UDP, or other transport header.
4. Place attacker-controlled bytes in the extension-header area where the vulnerable parser will incorrectly look for transport-layer fields.
5. Send the crafted traffic through the vulnerable filtering path.
6. Use the parser desynchronization to make policy checks evaluate forged header data while the real packet carries otherwise-blocked traffic.

How to detect it

There may be no host-level exploit artifact because successful exploitation can consist only of crafted network packets causing incorrect firewall decisions. Detection should focus on network telemetry, firewall decision logs, packet captures, and nftables rule logging. Review accepted or forwarded encapsulated IPv6 traffic that contains IPv6 extension headers before the transport header, especially where policy should have denied the real TCP or UDP destination. Compare nftables accept/drop logs with upstream or downstream network observations to identify traffic that was allowed despite violating expected segmentation policy. If packet capture is available, inspect tunneled or inner IPv6 packets for extension-header chains followed by a transport header where bytes at offset 40 resemble allowed port or protocol values but the actual transport header later in the packet contains different values. On Linux systems, review active nftables rulesets for inner-packet matching and correlate with unusual accepted flows. No named threat actors, ransomware campaigns, or confirmed exploitation are currently provided for this vulnerability.

What your security team should do

• Inventory Linux systems using nftables/netfilter for firewalling, routing, gateway, container, or overlay-network enforcement roles.
• Prioritize patching systems that inspect inner IPv6 packet headers or process tunneled/encapsulated IPv6 traffic.
• Review nftables rulesets for inner-header matches and determine whether any security decision depends on inner IPv6 transport protocol or port fields.
• If patching is delayed, restrict or drop unnecessary encapsulated IPv6 traffic and IPv6 packets with complex or unexpected extension-header chains at upstream controls.
• Monitor for anomalous accepted IPv6 tunneled traffic that should have been denied by policy, especially traffic containing extension headers before the transport header.
• Track vendor advisories for exact fixed kernel package versions and ensure systems are rebooted into the patched kernel.
• Because this is not currently in CISA KEV and has low EPSS, treat it as urgent for exposed filtering infrastructure but lower priority for Linux systems that do not process relevant nftables inner IPv6 traffic.