By ByteBot
A security researcher presented NatJack at Black Hat USA 2026 this week — an attack class that manipulates NAT connection tracking tables to hijack TCP sessions, poison DNS, and force denial of service. Every tested OS is affected: Windows, Linux, and macOS, across 32 products from 13 vendors. The central finding: a full patch is impossible because the flaw lives in the RFC specifications that define how NAT works, not in any vendor’s code.
What NatJack Does
NAT devices maintain a connection tracking table — a record of which internal IP/port maps to which external IP/port for each active connection. NatJack manipulates that table directly. Researcher Malcolm Stagg, an independent researcher and Synack Red Team member, disclosed four distinct techniques at Black Hat:
- TCP session hijack: A crafted SYN+RST packet sequence tears down the victim’s active NAT mapping. The attacker claims the freed slot before the connection can recover.
- DNS poisoning: The attacker floods the NAT table with dummy entries to evict the victim’s pending DNS mapping, inserts a replacement pointing to the attacker’s machine, and intercepts the DNS response to inject a forged answer.
- Port inference: By probing NAT table state, the attacker determines which source port a victim’s connection is using — useful for targeting subsequent attacks.
- NAT table exhaustion: Flooding the table blocks all new connections, a straightforward denial of service.
The attack requires privileged access to a machine behind the same NAT as the target — no IP spoofing, no broadcast domain access. That bar is lower than it sounds: a compromised container on the same Kubernetes node, a co-tenant VM on the same cloud host, or another device on the same office network all qualify.
Why Every OS Is Vulnerable
Windows, Linux, and macOS share no NAT code. They were written independently, by separate teams, across decades. All three were confirmed vulnerable in Stagg’s testing. The only explanation: the vulnerability lives in the design assumptions shared across RFC specifications, not in any implementation. NAT was standardized to translate addresses between network boundaries, not to validate that co-tenants behave honestly. That assumption was acceptable in 1999. It is not acceptable in 2026.
Two implementation-specific CVEs were assigned where vendor code made the underlying design flaw particularly easy to exploit:
- CVE-2026-56181 (CVSS 8.3) — Windows NAT in Hyper-V. Patch available.
- CVE-2026-63913 (CVSS 8.2) — Linux Netfilter conntrack. Fixed in kernel versions 5.10.259, 5.15.210, 6.1.176, 6.6.143, 6.12.93, 6.18.35, 7.0.12, and 7.1.
Apply these patches. But understand that patching these CVEs does not close the broader NatJack attack class. The patches harden specific behaviors — they do not rewrite the architecture of how NAT connection tracking works.
Who Is Most Exposed
If your workloads share a NAT boundary with anything untrusted, pay attention. Stagg identified the highest-priority scenarios:
- Shared Kubernetes nodes where multiple tenants deploy containers
- Container hosts running untrusted code alongside production services
- Virtual-desktop platforms and developer virtualization environments
- Multi-tenant egress gateways in cloud infrastructure
- Any setup where compromised or untrusted guests share a NAT device with sensitive traffic
As of August 7, 2026, no public evidence of NatJack techniques being exploited in the wild. That window will not stay open indefinitely.
What to Do
Three actions, in order of urgency:
Patch first. Apply the Linux kernel stable updates and the Windows Hyper-V patch for CVE-2026-56181. This removes the most easily exploited attack surface even if it does not close everything.
Stop trusting NAT as a boundary. Security practitioners have said “NAT is not a firewall” for twenty years. NatJack is the peer-reviewed proof. Separate untrusted workloads from trusted systems at the network level — real segmentation means separate bridges, separate VLANs, or separate hosts where the risk warrants it.
Encrypt internal traffic. TLS on every internal connection means that even if a TCP session gets hijacked or a DNS response gets poisoned, the attacker cannot read or inject meaningful content. DNS-over-HTTPS or DNS-over-TLS eliminates the DNS poisoning vector entirely.
NatJack is not a novel concept — the idea of subverting NAT state has been explored academically for years. What is new is the systematic proof of exploitability across independently developed implementations, practical techniques for doing it, and a Black Hat stage to present it from. The “it’s in the spec, not the code” framing matters: it shifts the required response from “apply a patch and move on” to “rethink how you architect trust boundaries.”
