NatJack Challenges NAT Security Trust

Network administrators have long operated under the assumption that internal traffic remains isolated when protected by Network Address Translation (NAT). However, recent findings suggest this architectural reliance may be misplaced. At Black Hat USA 2026, independent researcher and Synack Red Team member Malcolm Stagg unveiled NatJack, a novel method for manipulating connection tracking tables that renders common network safeguards insufficient.

The Breakdown of NAT Assumptions

Originally conceived in the early 1990s as a temporary workaround for IPv4 address exhaustion, NAT was never intended as a security feature. The protocol functions by allowing multiple internal devices to share a single public IP address, operating on the implicit trust that devices within the same network are benign. NatJack demonstrates that this assumption of internal safety is increasingly problematic.

Unlike previous vulnerabilities such as NAT Pinning or NAT Slipstreaming, which typically required the victim to interact with a malicious website or targeted Application Level Gateways, NatJack operates directly on the NAT table. It does not require Layer 2 access, meaning that traditional security measures like VLAN segmentation or switch port isolation are largely ineffective against it. The research confirmed vulnerabilities across Windows, Linux, and macOS, indicating that the flaw is rooted in shared design assumptions rather than platform-specific bugs.

“I kind of ran into this attack entirely by accident. I noticed that I was sometimes getting responses that didn’t correspond to the packets that I was sending. That told me that there is some sort of corruption happening inside the NAT table.”

— Malcolm Stagg, independent researcher and Synack Red Team member

Mechanics of the NatJack Class

The NatJack research details four specific techniques that exploit the way NAT hardware and software track active sessions. These methods allow an attacker sharing a NAT boundary with a target to manipulate traffic at the infrastructure level:

• TCP connection hijacking: Utilizing the RFC 1337 TIME-WAIT Assassination mechanism to force connections into a closed state and replace them with attacker-controlled entries.
• DNS response poisoning: Intercepting and altering UDP-based DNS lookups to redirect traffic.
• Denial of service: Exhausting the capacity of the NAT table, resulting in a total loss of connectivity for all devices behind the NAT.
• Connection port identification: Mapping the specific port assignments NAT uses for active traffic, facilitating the other three attack vectors.

Vendor Responses and Security Gaps

The disclosure process for NatJack met with varying degrees of acknowledgment. While some vendors moved to address the flaw—resulting in CVE-2026-63913 for the Linux kernel and CVE-2026-56181 for Windows NAT—others argued the issues were inherent limitations of the transport layer rather than exploitable vulnerabilities. Both Cisco PSIRT and Apple Product Security emphasized that existing mitigations or the use of end-to-end encryption like TLS should be considered the primary defense, even though Stagg noted that encryption does not prevent an attacker from dropping or hijacking a connection.

Implications for Network Architecture

The persistence of the NatJack vulnerability suggests that relying on legacy network design choices may leave modern environments exposed. For enterprise teams, the core takeaway is that Layer 2 isolation is no longer a sufficient perimeter for untrusted traffic. As Stagg noted, businesses should prioritize monitoring for anomalous packet sequences, implement strict source IP protection, and isolate cloud workloads to ensure that critical services do not share NAT gateways with lower-trust traffic. Because these flaws are baked into the design of how NAT functions, defenders must shift their strategy toward verifying traffic integrity and restricting NAT capacity rather than assuming the network boundary is naturally impenetrable.