Introduction
For thirty years, NAT has played a quiet but foundational role in enterprise network architecture. Behind the acronym — Network Address Translation — sits a tacit assumption: machines sharing the same NAT table can be trusted with each other. That assumption is exactly what NatJack has come to dismantle.
When the Network Boundary Becomes an Illusion
Revealed at Black Hat USA 2026 by researcher Malcolm Stagg, the NatJack attacks exploit not an isolated bug in a specific implementation, but an architectural flaw baked into the very design of NAT. The findings are unambiguous: across 32 products and configurations tested from 13 different vendors, every single one proved vulnerable to at least one technique in the NatJack family.
The attack condition is relatively straightforward: the attacker must share the same NAT boundary as their target. In a shared office environment, a multi-tenant Hyper-V infrastructure, a container cluster, or a private cloud, that scenario is anything but rare.
Four Techniques, One Blind Spot
The NatJack toolkit breaks down into four distinct attack vectors:
- Active TCP session hijacking: By manipulating NAT table entries, an attacker can force an established connection into a closed state and then take control of it.
- DNS poisoning: UDP queries traveling within a shared NAT perimeter can be intercepted and their responses spoofed, silently redirecting clients without their knowledge.
- Mapped port discovery: It is possible to determine which external ports correspond to other clients' active connections, enabling precisely targeted follow-on attacks.
- NAT table exhaustion: By flooding the table with fictitious flows, the attacker prevents legitimate clients from establishing new connections — a stealthy denial-of-service that is nearly indistinguishable from genuine overload.
Two CVEs have been assigned for the most widely deployed implementations: CVE-2026-56181 for the Windows NAT used by Hyper-V (CVSS 8.3) and CVE-2026-63913 for Linux Netfilter conntrack (CVSS 8.2). Patches exist for both of these specific cases — Linux in its stable branches 5.10.259, 5.15.210, and 6.1.176, and Windows via this summer's security updates.
What This Means for Network and Security Teams
Here is the critical point: NatJack is not a vulnerability that a patch can fully close. The problem is conceptual. NAT was designed to translate addresses, not to isolate tenants. As long as uncontrolled workloads share the same NAT table as sensitive systems, the structural risk remains.
The practical implications for network and security teams are clear:
- VLAN segmentation and switch port isolation offer no protection against NatJack, which operates at layers 3 and 4 of the network model.
- Blanket encryption of internal traffic — systematic TLS, zero-trust architecture — remains the most robust defense against session hijacking and DNS poisoning.
- IP Source Guard can limit forged flow injection at the upstream layer.
- Hyper-V and private cloud architectures must isolate untrusted workloads onto separate NAT gateways, rather than relying on logical separation within a shared table.
The Trust Assumption Nobody Thinks to Question
What NatJack ultimately exposes is a systemic blind spot: IT teams inherit implicit security assumptions embedded in protocols designed decades ago, then carry those assumptions into contexts the protocols were never built to handle. NAT as a trust boundary is a convention, not a guarantee.
For CIOs and CISOs managing multi-tenant environments — whether through virtualization, containerization, or hybrid cloud — NatJack is a concrete wake-up call: network architecture must be rethought from the premise that co-tenants are potentially hostile, not presumed friendly by default.