NatJack: the NAT trust assumption that breaks under adversarial conditions
At Black Hat USA 2026, researcher Malcolm Stagg disclosed NatJack, an attack class that targets a design assumption built into every major NAT implementation: that devices sharing a NAT table can be treated as mutually trusted. That assumption worked for most of the internet's history. It does not hold when one of those devices is controlled by an attacker.
What NatJack actually does
An attacker positioned on the same NAT boundary as a victim can execute four distinct techniques. First, hijacking: by sending crafted packets that manipulate NAT connection tracking state, the attacker can redirect or inject traffic into active TCP connections belonging to other users on the same NAT. Second, DNS spoofing: by exploiting the NAT tracking logic, the attacker can spoof DNS responses for other devices. Third, port inference: the attacker can determine which ports are mapped to other active connections. Fourth, denial of service: exhausting the NAT table forces all mapped connections to drop.
Who is affected
Testing covered 32 products and configurations from 13 vendors. Every implementation tested was vulnerable to at least some NatJack techniques. Two CVEs have been assigned: CVE-2026-56181 (Microsoft Windows Hyper-V NAT) and CVE-2026-63913 (Linux kernel). macOS remains without a patch. Windows received a fix specifically to support Azure Kubernetes Service workloads; the broader Windows NAT implementation exposure is ongoing.
Why there is no complete fix
NatJack is not a coding error in a single product. It is a consequence of how NAT tables are designed to work. Any device sharing a NAT boundary with an attacker is exposed to some subset of these techniques regardless of patching status. Individual vendors can implement additional checks to limit specific attack vectors, but the root cause cannot be eliminated through patching.
What you should do
Treat shared NAT environments as partial trust boundaries, not full trust boundaries. This applies to cloud VMs on shared subnets, home networks with multiple devices, and co-location facilities. Where TCP session integrity matters, implement additional application-layer protections. For DNS, consider using DNS-over-HTTPS or DNS-over-TLS with pinned resolvers rather than relying on NAT-local DNS resolution. Monitor for unexpected NAT table exhaustion events, which may indicate active exploitation attempts.
Gigia Tsiklauri is a Security Architect and founder of Infosec.ge. Get in touch if you are assessing network segmentation risks in your environment.