For decades, Network Address Translation (NAT) has been employed as a primary means of managing IP addresses in larger networks, particularly to address the limitations of IPv4 address availability. The core assumption of NAT is that private addresses remain secure. However, new research presented by Malcolm Stagg at Black Hat USA 2026 challenges this notion.
Stagg, an independent researcher and member of the Synack Red Team, introduced a new attack class named NatJack. This approach targets the NAT connection tracking table and allows an attacker sharing the same NAT boundary as a victim to take over active connections, alter DNS responses, and execute denial-of-service attacks, all without relying on traditional methods like IP spoofing or access to the broadcast domain. Following testing on 32 products and configurations, all revealed some level of vulnerability to NatJack techniques.
Surprisingly, Stagg stumbled upon these vulnerabilities while observing unexpected responses in his network traffic. His findings indicated a significant flaw within the NAT trust model, which has been operational since the early 1990s as a temporary solution for IPv4 address exhaustion. Stagg noted that the under-specification of some RFCs allowed NAT behavior to assume trust between connected peers, a trust that is increasingly misplaced.
While NAT has previously faced vulnerabilities, with notable examples being NAT Pinning and NAT Slipstreaming, NatJack distinguishes itself by directly manipulating NAT tables without requiring the victim’s engagement. This vulnerability extends across different operating systems, including Windows, Linux, and macOS, indicating a collective design weakness rather than isolated bugs in specific implementations.
NatJack includes four main attack techniques built upon the shared vulnerability of NAT table tracking:
- TCP Connection Hijacking: An attacker can spoof packets to close a victim’s connection and reroute it to themselves.
- DNS Response Poisoning: This technique modifies DNS responses, redirecting victim lookups.
- Denial of Service: By exhausting the NAT table, attackers can sever connectivity for all devices using that NAT.
- Connection Port Identification: Attackers can discover the port assigned to an active connection, facilitating the other techniques.
Stagg responsibly disclosed these issues; however, the responses from vendors varied significantly. Some, like Microsoft, acknowledged and patched vulnerabilities, while others, including the Linux kernel security team, initially dismissed Stagg’s findings as unfounded. Other companies, such as Cisco and Apple, claimed these are inherent design limitations within NAT rather than security vulnerabilities.
Although modern encryption methods may provide some protection against the consequences of an attack, they do not fully alleviate the risk posed by NatJack. Encryption may prevent the interception of data over a hijacked connection, but it does not prevent the hijacking itself.
In light of these findings, Stagg recommends several mitigation strategies for network professionals:
- Monitor NAT tables for indicators of compromise.
- Implement source IP protection to block spoofed packets.
- Isolate untrusted traffic on different subnets or VLANs.
- Disable loose connection tracking modes.
- Restrict network access for untrusted containers and isolate workloads in cloud environments.
Stagg emphasizes that the issues revealed by NatJack signal a need for broader awareness of NAT’s vulnerabilities. He urges the industry to reassess historical designs and assumptions, noting that reliance on outdated threat models could leave networks exposed.
