Researcher Malcolm Stagg presented a technique at Black Hat USA 2026 that hijacks TCP sessions and spoofs DNS by manipulating network address translation (NAT) table state. Named NatJack, the approach targets Windows NAT in Hyper-V and Linux Netfilter conntrack, and two CVEs have been assigned to the flaws it exposes.
The Two CVEs Behind NatJack and What They Affect
CVE-2026-56181, rated CVSS 8.3, affects Windows NAT and Hyper-V, while CVE-2026-63913, rated 8.2, affects Linux Netfilter conntrack. The research shows that NAT translation logic can be abused to redirect or hijack connections between internal hosts, bypassing the network boundaries that NAT is supposed to introduce.
The Privileged-Access Requirement and the Absence of a Single Patch
NatJack requires privileged access on a system behind the same NAT as the victim, so it does not target an unauthenticated remote attacker. No single patch fully closes the issue, because the technique abuses NAT semantics rather than a specific parsing bug. Vendors are expected to ship hardening for the two CVEs, but the underlying behavior will persist.
Why NAT Isn’t a Security Boundary
NatJack demonstrates that NAT, commonly treated as a crude firewall that enforces network isolation, can be abused against the trust model it creates. Hosts behind the same NAT assume the translation layer protects them from one another. An attacker with enough access inside that range can hijack a session or spoof DNS responses the targeted host does not expect to receive from an internal source.
The DNS Spoofing and TCP Redirection Consequences
Within the shared boundary, the manipulation lets an attacker redirect TCP sessions between internal hosts or inject spoofed DNS responses that direct the victim to attacker-controlled destinations. For an organization running many hosts behind dense internal NAT segments, the practical risk is that a single compromised privileged host becomes a pivot for widespread connection hijacking.
What the NatJack Research Means for Network Teams
The research shows that NAT is routing logic, not a security control. Reducing the number of privileged accounts on shared infrastructure narrows the pool of hosts that can attempt the manipulation, and segmenting NAT boundaries limits the reach of a successful hijack before it can spread.
Defense-in-Depth Because No Universal Patch Exists
Because the technique has no single patch, the response recommended by the researcher is defense-in-depth rather than a universal fix. Network teams should monitor NAT state for unusual session transitions, reduce the privileged account footprint, and apply vendor hardening for CVE-2026-56181 and CVE-2026-63913 as it becomes available.
NatJack is less notable as a practical remote attack than as a correction to the assumption that NAT enforces isolation. The two CVEs give vendors a concrete target to harden, but the deeper finding is architectural: the trust attached to network-address-translation boundaries does not survive a privileged insider. As organizations consolidate infrastructure behind shared NAT and dense internal segments, that boundary model must yield to segmentation and privileged-account discipline, because it is NAT logic — not firewall rules — that now carries the trust.
The research also fits a pattern in which controls many enterprises rely on as security boundaries are shown to be routing mechanisms rather than security functions. NAT was never designed as a firewall, yet it is commonly treated as one for practical defense. What NatJack demonstrates is that the same session bookkeeping an operator assumes is passive can be turned into an active hijacking primitive from inside the shared segment. For teams aware of how much lateral movement happens inside their own networks, the finding argues for treating the internal boundary with the same rigor normally reserved for the external edge, and for rotating the privileged accounts that live in the same shared address space.
