NatJack attacks hijack TCP sessions and spoof DNS through NAT table manipulation

Security researcher Malcolm Stagg unveiled a new attack class called NatJack at Black Hat USA 2026 that manipulates network address translation tables to hijack active TCP sessions, spoof DNS responses, and exhaust NAT infrastructure.

The disclosure marks a significant moment for network security professionals. NatJack does not target a single product or vendor — it exploits a foundational assumption embedded in many NAT implementations: that hosts sharing the same NAT environment will not interfere with each other's connection state. That assumption, it turns out, is dangerously optimistic.

What NatJack Does and How It Works

Stagg, conducting research independently through SODIUM-24, identified four primary attack paths that NatJack enables. Each path exploits the attacker's ability to manipulate connection-tracking entries belonging to another system on the same NAT.

• The first path redirects traffic from an active TCP connection by replacing its NAT mapping entirely.
• The second intercepts a victim's DNS request so the legitimate DNS response reaches the attacker first — allowing a forged response to be sent back in its place.
• The third technique exposes externally mapped ports that should remain hidden.
• The fourth floods the NAT connection table with spoofed flows until legitimate clients can no longer create new connections — a denial-of-service scenario with serious operational implications.

Stagg tested the techniques against dozens of real-world network infrastructure products from multiple vendors and demonstrated proof-of-concept exploitation in a controlled environment. As of August 7, 2026, The Hacker News found no public evidence that NatJack techniques have been exploited in the wild.

What makes NatJack particularly significant is that it does not require the attacker to break encryption or compromise a device outright. An attacker positioned within the same NAT boundary — a co-tenant on a shared hosting platform, a compromised VM in a virtualized environment, or a malicious actor on the same corporate subnet — can interfere with another host's active sessions without ever touching that host directly. This lateral movement capability within a NAT boundary is a credible and underappreciated threat vector.

Why NAT Was Never Designed as a Security Boundary

NAT was originally conceived as a mechanism for conserving IP address space, not as a security control. Security teams have long relied on it as an implicit trust boundary, but NatJack exposes the practical danger of that reliance. Understanding network firewall best practices and how to enforce proper security boundaries is increasingly important as research like NatJack demonstrates that shared infrastructure assumptions can be systematically exploited.

CVEs Assigned to Windows and Linux Implementations

Two implementation-specific vulnerabilities have been formally assigned CVEs following the research.

CVE-2026-56181: Windows NAT and Hyper-V

CVE-2026-56181 carries a CVSS score of 8.3 and affects Windows NAT as used by Hyper-V. Microsoft describes the flaw as an origin-validation error that enables spoofing from an adjacent network. Affected Windows releases include:

• Windows 11 24H2 before build 26100.8875
• Windows 11 25H2 before build 26200.8875
• Windows 11 26H1 before build 28000.2525
• Windows Server 2025 before build 26100.33158

The Hyper-V context is particularly consequential. In virtualized environments where multiple workloads share the same NAT infrastructure by default, a single compromised or malicious virtual machine could exploit this flaw to interfere with sessions belonging to entirely separate tenants or workloads.

CVE-2026-63913: Linux Netfilter Conntrack

CVE-2026-63913 carries a CVSS score of 8.2 and affects Linux Netfilter conntrack. According to the kernel.org CNA record, a crafted SYN packet followed by a reset packet with an invalid sequence number can prematurely force an active NAT entry into a closed state. The conntrack logic failed to validate packet direction — a subtle but consequential oversight. Fixed stable kernel releases include versions 5.10.259, 5.15.210, 6.1.176, 6.6.143, 6.12.93, 6.18.35, 7.0.12, and 7.1.

Stagg has noted that the kernel change corrects the specific code flaw but only partially mitigates the broader downstream-spoofing technique. The fix increases attack complexity rather than eliminating the threat entirely — a distinction that matters for security teams assessing residual risk. Organizations running Linux-based infrastructure should treat the kernel update as a necessary first step, not a complete resolution.

Context, History, and What Organizations Should Do Now

Prior Research and How NatJack Extends It

NatJack does not emerge in a vacuum. The research builds directly on earlier work presented at NDSS 2024, which demonstrated TCP hijacking through NAT mapping manipulation and found 52 of 67 tested routers susceptible to the techniques involved. That prior study generated ten CVEs. NatJack extends that foundation and broadens the attack surface considerably.

The pattern here is instructive: foundational protocol assumptions that have persisted for decades are now being systematically examined, and the results are consistently sobering. For further background on how attackers exploit gaps in network-layer controls, the guide to intrusion detection systems and how they identify suspicious network activity provides useful context on detection-layer defences that complement patching.

Mitigation: A Layered Response Is Required

There is no single universal patch for the NatJack attack class as a whole. Because the vulnerability stems from a design assumption rather than a single coding error, mitigation requires a layered response.

Organizations should apply available Windows and Linux updates immediately. Beyond patching, the research recommends encrypting traffic even within internal networks — a practice that many organizations skip under the mistaken belief that internal traffic is inherently safe. IP Source Guard is also recommended where applicable.

Perhaps most critically, Stagg's mitigation guidance emphasizes separating untrusted workloads from trusted systems that share NAT infrastructure. In virtualized and cloud environments — where Hyper-V, containers, and shared networking are commonplace — this separation is not always enforced by default. Robust network segmentation strategies that isolate workloads by trust level are among the most effective structural controls available against NatJack-class techniques.

The NatJack site does not publish a complete product-by-product vulnerability matrix, meaning organizations cannot rely on a single reference to determine their exposure across all vendors. This places the burden of assessment squarely on security and infrastructure teams to audit their own environments.

Concrete Steps for Network Defenders

The broader implication of NatJack is that the heist doesn't require breaking into the vault directly — an attacker can simply manipulate the building's internal routing system while everyone assumes the guards will handle it. Network defenders can take several concrete steps based on what NatJack reveals.

1. Review and enforce workload isolation policies in any environment where multiple tenants or trust levels share NAT infrastructure — particularly Hyper-V and Linux-based virtualization platforms.
2. Treat internal network traffic with the same encryption standards applied to external traffic; NatJack demonstrates that lateral movement within a NAT boundary is a credible threat.
3. Monitor for anomalous connection-table behavior and unusual DNS response timing, as both could serve as early indicators of NatJack-style activity before a full session hijack is completed.

For organizations operating at scale, this research reinforces a broader principle: trust boundaries must be explicitly enforced, not assumed. NAT was never designed to carry the security load that modern network architectures have quietly assigned to it. NatJack makes that gap visible in a way that is difficult to dismiss. For additional technical guidance on how the wider research community is documenting and responding to this attack class, the Black Hat conference archives provide access to Stagg's full presentation materials and supporting research documentation.