Security teams have a new threat category to put on their radar: NatJack attacks. In recent research presented at Black Hat USA 2026, Malcolm Stagg described how an attacker can abuse Network Address Translation (NAT) behavior to take over active TCP sessions, spoof DNS answers, and disrupt connectivity.
The most important takeaway is that many NAT implementations assume devices sharing the same NAT won’t tamper with each other’s connection state. NatJack is designed specifically to challenge that assumption. Depending on the environment, the attacker can redirect live traffic, trick DNS resolution, reveal what internal ports are mapped externally, or even force NAT tables to fill up.
What are NatJack attacks?
NatJack is an attack class that manipulates NAT connection tracking entries. By influencing how NAT maps internal flows to external addresses and ports—and how it updates or validates those mappings—an attacker can interfere with a victim’s ongoing network activity.
Stagg reported that affected behavior was observed across independently developed implementations, including systems using Windows and Linux networking components. While details vary by platform, the underlying theme remains consistent: connection tracking state can be treated as something an attacker may be able to affect from another host behind the same NAT.
Why NAT becomes a target
NAT is widely deployed because it allows multiple internal hosts to share a limited set of public IP addresses. To do this, NAT devices and kernels keep state about connections (for example, TCP sessions) and associate them with translations that make return traffic reach the right internal endpoint.
Many deployments implicitly trust that only the legitimate internal host creates and drives the connection state. NatJack challenges that trust. In some scenarios, an attacker controlling a different system behind the same NAT can manipulate tracking entries that were created for the victim.
Four main ways the attack can play out
The research outlines multiple paths an attacker might use. While exact mechanics differ by platform, the impact can be severe because these techniques can target both the transport layer (TCP) and the name resolution layer (DNS).
1) Redirecting an active TCP session
One technique works by replacing the NAT mapping tied to an active connection. Instead of letting the victim receive its expected traffic, the attacker can steer traffic toward themselves by subverting the NAT association that should have kept the session bound to the original internal host.
2) Spoofing DNS responses
Another path interferes with the victim’s DNS query so that the legitimate response ends up with the attacker. With that information in hand, the attacker may send a forged DNS response back to the victim, redirecting where the victim tries to connect.
3) Revealing externally mapped ports
NatJack can also disclose which ports are mapped externally. That means an attacker could gain visibility into services that are reachable from outside the NAT, potentially helping further compromise planning.
4) Exhausting NAT tables
Finally, some techniques fill the NAT connection tracking table using spoofed flows. When legitimate clients can’t create new connections because the table is full or otherwise blocked, the result is effectively a denial-of-service condition driven by state exhaustion.
Who is likely to be able to attempt it?
Stagg notes that NatJack attacks generally require the attacker to have privileged access to a system located behind the same NAT as the victim. That doesn’t mean the threat is purely theoretical—internal environments often have mixed trust levels—but it does shape the mitigation strategy.
In other words, the most exposed scenario is one where untrusted or less-trusted workloads share NAT infrastructure with systems that handle sensitive trust boundaries.
Assigned CVEs and affected platforms
Two implementation-specific issues were assigned CVEs, each tied to how connection state is handled on different operating system platforms.
Windows NAT issue (Hyper-V)
For Windows NAT used by Hyper-V, the assigned vulnerability is CVE-2026-56181 with a CVSS score of 8.3. Microsoft’s CNA record characterizes it as an origin-validation error that can enable spoofing from an adjacent network.
Affected versions include:
- Windows 11 24H2 before 26100.8875
- Windows 25H2 before 26200.8875
- Windows 26H1 before 28000.2525
- Windows Server 2025 before 26100.33158
Linux Netfilter conntrack issue
On Linux, the conntrack-related issue is CVE-2026-63913 with a CVSS score of 8.2. The kernel.org CNA record describes a scenario where a crafted SYN followed by a reset packet with an invalid sequence number can prematurely force an active Netfilter NAT entry into a closed state, due to conntrack direction validation logic failing to properly validate it.
Fixed stable releases listed in the CNA record include:
- 5.10.259
- 5.15.210
- 6.1.176
- 6.6.143
- 6.12.93
- 6.18.35
- 7.0.12
- 7.1
Stagg emphasizes that the kernel change fixes the code flaw but primarily mitigates the downstream-spoofing aspect. In practice, this may increase the attacker’s complexity rather than eliminating the broader class of behavior.
Is there a single patch for NatJack?
No. The research indicates there is no single, one-size-fits-all patch that resolves the entire NatJack attacks class. Instead, organizations should focus on applying the available Windows and Linux updates that correspond to the documented CVEs and behaviors on their platforms.
Because the broader attack outcomes can involve multiple techniques, defenders should also consider layered controls that reduce the value of successful session or name-resolution tampering.
Mitigation guidance: focus on isolation and hardening
Mitigations in the research revolve around limiting trust between systems sharing NAT infrastructure and reducing the impact of manipulated state.
Separate untrusted workloads
The guidance stresses separating untrusted workloads from trusted systems that share NAT infrastructure. If an attacker can reach a host behind the same NAT, the attacker’s ability to manipulate NAT connection tracking becomes part of the threat model.
Encrypt traffic even internally
Another recommended control is encryption of traffic even within internal networks. Encryption can help reduce the usefulness of session hijacking and DNS redirection by protecting confidentiality and integrity—depending on how the application protocols are deployed.
Apply Internet Protocol Source Guard where applicable
The research also recommends using Internet Protocol (IP) Source Guard in environments where it applies. The intent is to strengthen protections against spoofing by validating source addressing at the network access layer, making it harder for an attacker to fabricate traffic identities.
Testing and real-world context
Stagg reports that he tested techniques against dozens of real-world network infrastructure products from multiple vendors. In addition, he demonstrated proof-of-concept exploitation in a controlled environment.
As of August 7, 2026, the available public information described in the article did not show evidence that NatJack attacks had been exploited in the wild. However, the lack of public exploitation records doesn’t remove the need for patching and segmentation—especially when the prerequisites align with common internal deployment patterns.
NatJack builds on earlier NAT-state research
This work builds on earlier findings about NAT state manipulation. A referenced NDSS 2024 study demonstrated TCP hijacking through NAT mapping manipulation and found that 52 out of 67 tested routers were susceptible. That earlier research also produced ten CVEs.
In that context, NatJack can be viewed as a continuation of a line of research focused on how NAT and connection tracking assumptions can fail under adversarial conditions.
What defenders should do next
If you operate NAT-heavy networks—especially where Windows Hyper-V components, Linux conntrack, or similar connection tracking mechanisms are involved—start by reviewing patch status for the relevant Windows and Linux vulnerabilities described above.
Then implement defense-in-depth: isolate untrusted workloads, encrypt internal traffic, and consider network-side protections such as IP Source Guard where it fits your architecture. Taken together, these measures reduce the likelihood that a single compromised host behind the same NAT can pivot into session hijacking, DNS spoofing, port disclosure, or NAT exhaustion.
NatJack attacks highlight a critical lesson: NAT is not just a routing convenience—it is also a stateful security boundary that must be managed with strict trust assumptions.
Source: https://thehackernews.com/2026/08/new-natjack-attacks-hijack-tcp-sessions.html
