CVE-2026-64006

What it actually does

This Linux kernel netfilter nf_tables flaw causes incorrect handling of nftables bitwise left-shift and right-shift operations when the source and destination registers are the same or partially overlap. The kernel writes shifted data to the destination register and then incorrectly reuses the modified value while calculating carry data for the next 32-bit word. The result is corrupted register state and incorrect nftables rule evaluation. In practical terms, crafted nftables rules can behave differently than intended, potentially causing firewall policy bypass, packet misclassification, or unexpected filtering behavior. Exploitation generally requires the ability to create or modify nftables rules, typically CAP_NET_ADMIN in the relevant network namespace, or access to an environment where unprivileged user namespaces grant a path to netfilter rule manipulation.

Why it matters to the business

Systems relying on nftables for host firewalling, container isolation, traffic filtering, or network policy enforcement could make incorrect allow/deny decisions if a crafted or malformed rule triggers the flaw. The most likely operational consequence is unreliable packet filtering rather than direct remote code execution. Because the issue is in the Linux kernel and netfilter is widely used across servers, appliances, cloud images, and container platforms, exposure depends on whether vulnerable kernel versions are deployed and whether local users, containers, orchestration components, or administrators can create nftables rules. The CVE is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has a low EPSS score, so urgency is primarily driven by local privilege boundaries and dependence on nftables for security controls.

How an attack unfolds

An attacker first needs a way to submit nftables rules to the kernel, such as local access with CAP_NET_ADMIN, access inside a network namespace where nftables administration is permitted, a compromised privileged container, or control of an automation path that applies firewall rules. The attacker then creates nftables bytecode using a bitwise shift operation where the source and destination registers are the same or overlap. When traffic reaches the affected chain, the vulnerable kernel evaluates the rule and corrupts the register value during the shift/carry calculation. The corrupted value can cause subsequent comparisons or verdict logic to match incorrectly. Depending on the surrounding ruleset, this may let traffic be accepted when it should be dropped, dropped when it should be accepted, or otherwise routed through unintended policy paths. There is no public evidence in the supplied data of mature exploit code, named threat actor use, KEV listing, or ransomware use.

How to fix it

Apply a Linux kernel update from the relevant distribution or kernel vendor that includes the upstream nf_tables fix for same-register and partially overlapping bitwise operations. Because no product-specific fixed versions were provided, use vendor advisories for the exact patched kernel package for each distribution, appliance, container host, or cloud image. Reboot into the updated kernel after installation; merely installing the package is insufficient if the running kernel remains vulnerable. Where immediate patching is not possible, reduce exposure by limiting CAP_NET_ADMIN, disabling or restricting unprivileged user namespaces where operationally feasible, preventing privileged containers from managing host firewall rules, and limiting nftables rule changes to trusted automation and administrators. Review nftables rulesets for unusual bitwise shift operations, especially rules using shifts with overlapping source and destination registers.

How to confirm the fix worked

Confirm the running kernel version includes the vendor patch, not just that an updated package is installed. Validate with commands such as `uname -r` and the distribution package manager, then compare against the vendor advisory for this CVE or the relevant kernel changelog mentioning the nf_tables same-register shift fix. Dump active nftables rules with `nft list ruleset` and review for unexpected bitwise shift logic. If a test environment is available, reproduce the vendor or upstream nftables bytecode behavior before and after patching: on vulnerable kernels, same-register shift operations may produce incorrect comparison results; on fixed kernels, the shifted result should be calculated consistently and partially overlapping register operations should be rejected by the control plane. Also verify that untrusted users and containers cannot obtain CAP_NET_ADMIN or modify nftables rules unless explicitly required.

Typical attack path

1. Gain local or namespace-level capability to create or modify nftables rules, commonly CAP_NET_ADMIN or equivalent control through a privileged container or firewall automation path.
2. Create an nftables table, chain, and rule using bitwise left-shift or right-shift operations with the same or overlapping source and destination register storage.
3. Cause matching network traffic to traverse the crafted nftables chain.
4. Trigger incorrect register carry calculation during rule evaluation in the vulnerable kernel.
5. Use the resulting incorrect comparison or verdict behavior to influence firewall decisions, such as bypassing an intended packet filter or disrupting expected network policy.

How to detect it

To determine whether this was already exploited or triggered, focus on evidence of nftables rule creation or modification rather than network payloads, because exploitation requires crafted local firewall rules and does not have a reliable remote packet signature. Review shell history, sudo logs, auditd logs, EDR process telemetry, and package or configuration-management logs for executions of `nft` or direct netlink-based firewall management. Inspect `nft list ruleset` output and historical configuration backups for bitwise shift operations, especially left-shift or right-shift expressions that write back into the same register or use overlapping data. Check `/var/log/auth.log`, `/var/log/secure`, audit logs, and container runtime logs for users or containers obtaining CAP_NET_ADMIN, running privileged containers, creating network namespaces, or applying unexpected nftables rules. If auditd is enabled, look for executions of `/usr/sbin/nft`, `/sbin/nft`, or processes opening netlink sockets for netfilter configuration around the time firewall behavior changed. Also investigate symptoms such as unexplained firewall bypasses, unexpected packet counters on rules containing bitwise expressions, or nftables rules added outside approved change windows. Kernel logs are unlikely to show a definitive exploit marker unless the malformed rule caused an error or warning, so absence of kernel errors should not be considered proof of no exposure.

• /usr/sbin/nft
• /sbin/nft
• nft add table
• nft add chain
• nft add rule
• nft -f
• nft list ruleset
• bitwise reg
• << 0x
• >> 0x
• reg 1 = ( reg 1 <<
• reg 1 = ( reg 1 >>
• CAP_NET_ADMIN
• --cap-add=NET_ADMIN
• --privileged
• unshare -n
• ip netns add
• NETLINK_NETFILTER
• nf_tables

What your security team should do

• Inventory Linux systems that use nftables, including container hosts, Kubernetes nodes, network appliances, firewalls, VPN gateways, and hardened server images.
• Prioritize patching systems where nftables enforces security boundaries or where local users, containers, or automation can create network namespaces or modify netfilter rules.
• Confirm patched kernels are actually running after reboot or live-patch application.
• Restrict CAP_NET_ADMIN and privileged container usage; treat either capability as high risk on vulnerable kernels.
• Disable or tightly control unprivileged user namespaces where they are not required, especially on multi-user systems.
• Review recent nftables changes for unusual bitwise shift operations, same-register transformations, or rules added outside approved change windows.
• Monitor for local execution of `nft`, unexpected netfilter configuration changes, and privileged container activity that modifies firewall state.
• Do not treat the low EPSS score as a reason to ignore the issue on systems where nftables is part of a critical security control.