NAT (Network Address Translation) has been a fundamental technology for managing IP addresses in larger networks, especially amid the scarcity of IPv4 addresses. However, recent findings suggest that reliance on NAT may be misplaced, particularly regarding security assumptions about the isolation of private addresses.
At Black Hat USA 2026, researcher Malcolm Stagg, part of the Synack Red Team, introduced an attack methodology known as NatJack. This attack exploits the NAT connection tracking table, allowing attackers sharing a NAT boundary with a target to hijack connections, poison DNS responses, and initiate denial-of-service attacks. This vulnerability eliminates the need for traditional layer 2 exploits like IP spoofing.
Stagg's exploration into NAT flaws was largely serendipitous. He stumbled upon discrepancies in expected network packet responses, indicating potential corruption within the NAT configuration. “I kind of ran into this attack entirely by accident,” he recounted, emphasizing the alarming implications of his discovery.
Understanding the Flaws in NAT's Trust Model
NAT, which emerged in the early 1990s as a workaround to IPv4 address depletion, was not designed with security in mind. The core assumption is that peers on the same network can be trusted. Stagg noted that “under-specification in some of the RFCs” allows behavior based on this outdated trust model.
Previous attacks have exploited weaknesses in the NAT framework, such as NAT Pinning disclosed by security researcher Samy Kamkar, and NAT Slipstreaming revealed in 2020. These earlier vulnerabilities required direct user interaction, but NatJack represents a more sophisticated level of exploitation that does not require any action from the victim beyond having an active session.
This exploit's sophistication is underscored by the fact that it transcends Layer 2 vulnerabilities—VLAN segmentation and switch port isolation offer no protection, as the attack primarily targets shared NAT infrastructure across Layer 3 and Layer 4. Stagg identified the same design flaws existing in multiple OS environments, including Windows, Linux, and macOS, illustrating a systemic issue rather than isolated bugs.
Attack Techniques and Their Implications
NatJack employs four specific attack techniques, unified by a single critical weakness in how NAT handles connection tracking:
- TCP connection hijacking: Attackers can force a victim’s connection into a closed state using spoofed packets, then inject their identifiers into the NAT table, taking control of that connection.
- DNS response poisoning: This technique involves altering DNS responses as they pass through the NAT, effectively redirecting a victim’s online inquiries.
- Denial of service: An attacker might overwhelm the NAT table, disrupting service for all devices sharing that NAT.
- Connection port identification: NAT mapping allows attackers to ascertain which port has been assigned to an active connection, facilitating other attack techniques.
Vendor Responses to NatJack
Stagg responsibly disclosed the vulnerabilities, yet responses from vendors have varied dramatically. Initially, the Linux security team skeptically dismissed the findings. “I was pretty surprised by that,” Stagg remarked, reflecting the frustration of outlining significant vulnerabilities only to face resistance.
Eventually, the Linux kernel received a patch to accommodate Azure Kubernetes Service after Microsoft’s intervention, generating CVE-2026-63913. Other vulnerabilities, such as Microsoft's own CVE-2026-56181, relate directly to the NAT vulnerabilities in Hyper-V.
Contrarily, other vendors framed Stagg’s findings as inherent limitations of NAT design rather than outright security flaws. For instance, Cisco’s response indicated that known mitigations already existed for affected products. Similar positions were adopted by Apple, which reasoned that NAT behavior stems from known transport layer issues rather than actual vulnerabilities.
Stagg highlights that while encryption can mitigate some risks associated with NatJack, it doesn’t eliminate them. “Encryption is a great help here,” he acknowledges, while stressing that it does not prevent attackers from hijacking connections.
Mitigating Risks in the Wake of NatJack
Despite the absence of universal patches, there are proactive measures that network administrators can implement to reduce risks:
- Monitor NAT tables: Keep an eye out for near-full NAT tables, unusual traffic patterns, and erratic packet sequences.
- Enable source IP protection: Implement features like IP Source Guard to prevent spoofed packets from reaching critical areas.
- Segment untrusted traffic: Isolate untrusted users onto dedicated subnets or VLANs and impose connection limits.
- Disable loose connection modes: Deactivate configurations that allow loose connection tracking, which can exacerbate vulnerabilities.
- Restrict container network access: Limit network access for untrusted containers, ensuring that they do not operate with elevated privileges.
- Isolate cloud workloads: Keep untrusted and trusted workloads distinct, assigning unique IPs to serverless functions.
Stagg stresses the significance of these preventive measures, indicating that vulnerabilities persist even among different subnets. The essential takeaway from NatJack is that many networks are susceptible to risks previously thought contained, with design assumptions made in earlier technology eras now coming back to haunt modern implementations. It urges network professionals to reassess these foundational design principles and adjust strategies in response to current threat models.
