For decades, network address translation has done quiet, thankless work: mapping a crowd of internal devices onto a handful of public addresses and remembering which reply belongs to whom. A new class of attacks called NatJack goes after an assumption baked into that plumbing, namely that machines sitting behind the same NAT will not reach over and tamper with one another’s connections. Independent researcher Malcolm Stagg, who runs SODIUM-24 and serves on the Synack Red Team, laid it out at Black Hat USA 2026.
The core idea is unsettling in its simplicity. A NAT device keeps a state table matching internal IPs and ports to external ones. If an attacker already controls a privileged system behind the same gateway as the victim, they can, depending on the implementation, edit entries that belong to someone else.
Four ways to abuse the table
Stagg grouped the work into four techniques. One rewrites the NAT mapping on a live TCP connection to redirect its traffic to the attacker. Another nudges a victim’s DNS request so the real answer lands with the attacker, who fires back a forged reply. The other two are quieter: revealing which external ports a target has mapped, and flooding the table with junk flows until legitimate clients can no longer open a connection.
None of this needs Layer 2 access or any action from the victim beyond being on the wrong side of the same NAT. That puts the risk exactly where trusted and untrusted workloads share infrastructure: multi-tenant cloud, container hosts, VM platforms, and ordinary corporate networks.
A bug, or a broken assumption?
Here is where it gets interesting. Stagg tested 32 products across dozens of configurations and found every one vulnerable to at least some of the techniques. Windows, Linux, and macOS were all affected, three systems that share no NAT code at all. When the same weakness turns up in software written by people who never spoke to each other, you are usually looking at a shared idea rather than a shared typo.
Two implementations drew formal CVEs: CVE-2026-56181 (CVSS 8.3) in the Windows NAT that Hyper-V relies on, and CVE-2026-63913 (CVSS 8.2) in Linux Netfilter’s connection tracking, where a crafted SYN followed by a bogus reset could tear down an active entry early. Fixes have shipped in current Windows builds and recent stable kernels, though Stagg is blunt that the Linux patch raises the cost of the downstream spoofing trick without killing it.
Not everyone agreed there was a hole to close. Cisco and Apple declined to treat the findings as vulnerabilities, calling them known limitations of NAT and the transport layer, with Apple noting that modern security models already assume the local network may be hostile.
What to actually do
Because no single patch covers the whole class, the defense has to be layered. Apply the Windows and Linux updates, encrypt traffic even inside your own network, and switch on IP Source Guard where the gear supports it. The structural fix is to stop treating a NAT boundary as a fence between tenants and keep untrusted systems off the same gateway as the ones you care about.
No one has been caught using NatJack in the wild yet, at least as of early August. The sharper question is whether your own architecture has quietly been trusting a NAT table to do a job it was never built to do.
This website uses cookies.