CVE-2026-53218

What it actually does

This is a Linux kernel netfilter/nftables information disclosure flaw in the nft_exthdr expression. When userspace creates an nftables rule using the extension-header “present” flag, the kernel incorrectly tracks a user-controlled length as initialized register data even though the evaluation path only writes 1 byte, or 4 bytes on one error path. If the requested length is greater than the bytes actually written, the remaining nftables virtual registers may contain stale, uninitialized stack data. A local attacker who can create or manipulate nftables rules may be able to cause kernel memory contents to influence rule evaluation or be exposed through observable nftables behavior.

Why it matters to the business

Successful exploitation could leak sensitive kernel memory values, which may help an attacker defeat exploit mitigations or chain this issue with another local kernel vulnerability for privilege escalation. The current public risk appears limited because exploitation requires nftables rule creation privileges or access to a namespace configuration that grants CAP_NET_ADMIN, the EPSS score is low, it is not listed in CISA KEV, and no mature public exploit is indicated. Systems that allow unprivileged user namespaces or run containerized workloads with network-administration capabilities have higher practical exposure.

How an attack unfolds

An attacker first needs a path to submit nftables netlink configuration to the kernel, typically by having CAP_NET_ADMIN or by entering a user/network namespace configuration that grants equivalent capability. The attacker then creates a crafted nftables rule using the nft_exthdr expression with NFT_EXTHDR_F_PRESENT set and a length larger than the amount the kernel actually writes. During rule initialization, the kernel marks the larger destination register range as initialized, but during packet evaluation only the first byte, or in a TCP/DCCP error path four bytes, is written. The remaining bytes in the nftables register area retain stale stack contents. The attacker then triggers evaluation of the crafted rule with packets matching the rule path and attempts to make the stale register bytes affect an observable result, such as rule matching behavior, counters, verdicts, or other outputs. The flaw is primarily useful as an information leak and is more dangerous when combined with another memory-corruption or privilege-escalation bug that benefits from leaked kernel addresses or stack data.

How to fix it

Upgrade to a Linux kernel build that includes the netfilter nft_exthdr fix which rejects excessive requested lengths when NFT_EXTHDR_F_PRESENT is set. If no exact fixed version is available from the upstream product metadata, apply the latest security kernel from the relevant Linux distribution or vendor and reboot into the patched kernel. As interim risk reduction, restrict CAP_NET_ADMIN to trusted administrators and workloads, avoid running containers with unnecessary network administration capabilities, disable or restrict unprivileged user namespaces where operationally feasible, and limit nftables rule-management access to trusted automation and administrators only. These mitigations reduce exploitability but do not correct the kernel bug.

How to confirm the fix worked

Confirm that the running kernel is the patched vendor build, not merely that a package has been installed; verify with the active kernel version after reboot. Review vendor advisories or kernel changelogs for the netfilter nft_exthdr fix related to register tracking for the F_PRESENT flag. Validate that untrusted users and containers cannot create nftables rules unless explicitly required. Where practical, attempt a controlled negative test in a non-production environment: submitting an nft_exthdr present expression with an excessive length should be rejected by the patched kernel rather than accepted. Also confirm that user namespace and container capability policies match the intended hardening posture.

Typical attack path

1. Obtain the ability to create nftables rules, usually through CAP_NET_ADMIN, privileged container access, or permissive unprivileged user/network namespace settings.
2. Create an nftables rule containing an extension-header expression using the present flag with an excessive requested register length.
3. Trigger the rule by sending traffic that causes the vulnerable nft_exthdr evaluation path to run.
4. Observe nftables behavior or outputs that can be influenced by the uninitialized register bytes.
5. Use any leaked kernel memory values to support further exploitation, such as bypassing address randomization or improving reliability of a separate kernel exploit.

How to detect it

There is no reliable universal log artifact proving exploitation because the vulnerable behavior occurs inside kernel nftables rule evaluation and may not emit an error. Detection should focus on evidence of suspicious nftables rule creation and capability abuse. Review auditd, systemd journal, shell history, endpoint telemetry, container runtime logs, and netlink monitoring records for unexpected nftables changes, especially by users or processes that should not manage firewall rules. On systems with audit coverage, look for executions of nft, iptables-nft, or automation tools modifying nftables rules, and correlate with CAP_NET_ADMIN use, privileged container launches, user namespace creation, or unusual local traffic used to trigger crafted rules. Investigate nftables rules using extension-header matching with a present-test style expression and unusual length/register parameters. Because the issue is an information disclosure, absence of crashes or kernel warnings does not rule out exploitation.

What your security team should do

• Prioritize patching Linux systems where untrusted users, build jobs, containers, or sandboxed workloads may obtain CAP_NET_ADMIN or create user/network namespaces.
• Deploy the latest vendor-supported kernel containing the nft_exthdr F_PRESENT length validation fix and reboot systems to activate it.
• Audit container and orchestration policies for unnecessary CAP_NET_ADMIN, privileged mode, host networking, or nftables management permissions.
• Restrict unprivileged user namespaces where feasible, especially on multi-user servers and shared compute platforms.
• Monitor for unexpected nftables rule creation by non-administrative processes and investigate changes occurring outside approved configuration-management paths.
• Treat any suspected exploitation as a potential kernel memory disclosure and assess whether it may have been chained with other local privilege-escalation activity.