CVE-2026-53269

What it actually does

This is a race condition in the Linux kernel netfilter SYNPROXY infrastructure. SYNPROXY registers netfilter hooks on demand when the first iptables SYNPROXY target or nftables SYNPROXY expression is added. Concurrent rule creation through the iptables and nftables frontends can race while updating shared hook reference-counting state. The upstream fix serializes this reference-count control path with a mutex. The most likely technical impact is kernel instability, incorrect hook registration/unregistration, or denial of service through a kernel crash or degraded packet-filtering behavior. Exploitation generally requires the ability to modify netfilter rules, such as CAP_NET_ADMIN or equivalent administrative privileges, including inside a container or network namespace where that capability is granted.

Why it matters to the business

Organizations using Linux systems with netfilter SYNPROXY may face service disruption if a privileged local user, compromised administrative process, or over-permissioned container triggers the race. The practical risk is highest on systems where untrusted workloads are granted network-administration capabilities or where automation concurrently manages iptables and nftables rules. EPSS is currently low, it is not listed in CISA KEV, and no exploit maturity is reported, so broad opportunistic exploitation is not indicated; however, kernel-level availability issues can still affect firewalls, load balancers, gateways, Kubernetes nodes, and other Linux hosts performing packet filtering or SYN flood protection.

How an attack unfolds

An attacker first needs a foothold that can modify netfilter configuration, such as root access, CAP_NET_ADMIN, access to a privileged container, or control of firewall-management automation. The attacker then repeatedly and concurrently adds SYNPROXY rules through iptables and nftables, attempting to make both frontends register SYNPROXY netfilter hooks at the same time. Because vulnerable kernels do not serialize the shared hook reference-counting control path, the concurrent operations can corrupt or desynchronize the hook registration state. Successful triggering may result in a kernel warning, crash, panic, network filtering malfunction, or other denial-of-service condition. There is no indication from the provided data that this is remotely exploitable without netfilter rule-management privileges.

How to fix it

Apply a kernel update from the relevant Linux distribution or appliance vendor that includes the upstream fix for the SYNPROXY hook reference-counting race, specifically the change that adds mutex protection around SYNPROXY hook reference-count control. No exact fixed package versions were provided, so track vendor advisories for the running kernel branch and upgrade to the first fixed or later kernel release. As interim mitigations, restrict CAP_NET_ADMIN to trusted workloads only, avoid granting privileged or NET_ADMIN containers unless strictly required, serialize firewall automation that modifies SYNPROXY rules, avoid concurrent management of SYNPROXY through both iptables and nftables, and disable or avoid loading SYNPROXY-related functionality where it is not needed.

How to confirm the fix worked

Confirm the running kernel package is at or above the vendor-fixed release containing the SYNPROXY mutex/refcount fix. Validate with vendor changelogs or kernel source history for the netfilter SYNPROXY change. Inventory systems for SYNPROXY usage by reviewing iptables and nftables rulesets for SYNPROXY targets or expressions. Confirm that untrusted containers and users do not have CAP_NET_ADMIN. After patching, test representative iptables and nftables SYNPROXY rule creation under controlled conditions and monitor kernel logs for warnings, oopses, panics, or netfilter-related errors. A reboot is usually required for kernel updates to become effective unless the vendor provides a live patch that explicitly covers this issue.

Typical attack path

1. Obtain local administrative privileges or CAP_NET_ADMIN-equivalent permissions on a Linux system or within a network namespace/container.
2. Confirm that netfilter, iptables or nftables, and SYNPROXY support are available.
3. Launch concurrent rule updates that add SYNPROXY targets or expressions through iptables and nftables.
4. Race the first-use hook registration path so both frontends manipulate SYNPROXY hook reference-counting state at the same time.
5. Trigger kernel instability, incorrect netfilter hook state, packet-filtering disruption, or denial of service.

How to detect it

To assess possible prior exploitation, review kernel logs and system journals for crashes, warnings, oopses, panics, or KASAN reports mentioning SYNPROXY, netfilter, nftables, iptables, or SYNPROXY-related kernel modules. Correlate those events with process execution, auditd, sudo, shell history, configuration-management logs, and orchestration logs showing iptables, iptables-restore, nft, or nft -f activity that adds SYNPROXY rules. Pay particular attention to bursts of concurrent rule updates, simultaneous iptables and nftables changes, or SYNPROXY modifications made by unexpected users, containers, CI/CD jobs, or automation accounts. In containerized environments, review container runtime and Kubernetes audit logs for privileged containers or added NET_ADMIN capability before kernel instability. Because the provided information does not include a known public exploit or unique payload, detection should focus on behavioral correlation: unexpected SYNPROXY rule changes followed closely by kernel faults, packet-filtering outages, node reboots, or firewall-service disruption.

• SYNPROXY
• -j SYNPROXY
• synproxy
• nft_synproxy
• xt_SYNPROXY
• nf_synproxy_core
• nft add rule
• iptables -A
• iptables-restore
• nft -f
• CAP_NET_ADMIN
• cap_add: NET_ADMIN
• --cap-add=NET_ADMIN
• privileged: true
• BUG: kernel NULL pointer dereference
• kernel panic
• Oops:
• KASAN:
• netfilter
• nf_hook

What your security team should do

• Prioritize patching Linux systems that expose packet-filtering, gateway, load-balancing, or DDoS-protection functions and use SYNPROXY.
• Identify workloads, containers, and service accounts with CAP_NET_ADMIN or privileged-container access; remove that capability where not required.
• Search configuration management, firewall automation, and orchestration jobs for concurrent iptables and nftables SYNPROXY modifications and serialize those workflows.
• Inventory current SYNPROXY usage with iptables-save and nft list ruleset, then disable unused SYNPROXY modules or rules where operationally safe.
• Monitor kernel logs for netfilter, SYNPROXY, oops, BUG, panic, or KASAN events until all affected kernels are updated.
• Treat unexpected firewall rule changes involving SYNPROXY as suspicious unless tied to approved administrative activity.