Two high-severity vulnerabilities — CVE-2026-56181 (CVSS 8.3) and CVE-2026-63913 (CVSS 8.2) — anchor a broader attack class that a security researcher calls NatJack, a set of techniques that manipulate NAT connection state to hijack TCP sessions, spoof DNS, reveal mapped ports and exhaust NAT tables.
What Malcolm Stagg disclosed at Black Hat USA 2026
Security researcher Malcolm Stagg, presenting work conducted through SODIUM-24, disclosed NatJack at Black Hat USA 2026. Stagg's research targets an assumption built into many NAT implementations: hosts behind the same NAT are generally assumed not to manipulate one another's connection state. The research shows that an attacker controlling a system behind the same NAT can, depending on the implementation, manipulate connection-tracking entries that belong to another system.
Stagg and testers from Synack evaluated dozens of real-world network infrastructure products from multiple vendors and demonstrated proof-of-concept exploitation in a controlled environment. The NatJack site does not publish a complete product-by-product matrix, and The Hacker News found no public evidence that NatJack techniques have been exploited in the wild as of August 7, 2026.
Four principal exploit paths NatJack uses
The research describes four main techniques attackers can use once they control a system behind the same NAT as a victim:
- Replacing a TCP mapping to redirect traffic from an active connection, effectively hijacking the session.
- Interfering with a victim's DNS request so that the legitimate DNS response is diverted to the attacker, who can then return a forged response.
- Disclosing externally mapped ports by manipulating connection-tracking state so that internal mappings become visible.
- Filling the NAT connection table with spoofed flows until legitimate clients cannot create new connections, a denial-of-service against the NAT itself.

This site is the portfolio.
OSINTSights runs on Cloudflare Workers, D1, R2, and Vectorize, with an AI pipeline on Hetzner ARM. Nubivance designed, built, and operates it. We do the same for clients.
See what we buildImplementation-specific flaws in Windows and Linux
Not all affected behavior is identical across products. Two implementation-specific flaws have been assigned CVEs and detailed in vendor CNA records:
- Windows: Microsoft's CNA record describes an origin-validation error that enables spoofing from an adjacent network. Affected releases listed are Windows 11 24H2 before 26100.8875, 25H2 before 26200.8875, 26H1 before 28000.2525, and Windows Server 2025 before 26100.33158. This is one concrete manifestation of the broader NatJack class.
- Linux: The kernel.org CNA record says 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 because the conntrack logic failed to validate its direction. Fixed stable releases that address the specific code flaw include 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 says the kernel change “fixes the code flaw but only mitigates the broader downstream-spoofing technique, increasing attack complexity rather than fully addressing it.” In other words, these fixes correct implementation bugs but do not eliminate the architectural assumptions that NatJack exploits.
Mitigations, patches and operational guidance
There is no single patch that removes the NatJack attack class. The published guidance is pragmatic and layered: apply available Windows and Linux updates that address the specific CVEs; architect networks to separate untrusted workloads from trusted systems that share NAT infrastructure; and encrypt traffic even within internal networks so that hijacked flows and spoofed DNS responses are less useful to an attacker. The research also recommends enabling Internet Protocol (IP) Source Guard where applicable.
Synack's testing demonstrates proof-of-concept exploitation only in a controlled environment; defenders should prioritize patching the documented Windows and kernel fixes and re-evaluate NAT-sharing policies between workloads and platform services.
What this means for technologists, procurement leaders, and end users
- Technologists and security teams: prioritize applying the Windows and Linux fixes listed in the vendor CNA records, segment untrusted workloads that share NAT devices with sensitive systems, and ensure internal traffic is encrypted to reduce the impact of session hijacking and DNS spoofing.
- Procurement leaders and vendors: ask vendors whether their NAT implementations were tested against NatJack techniques and require timelines for shipping the specific fixes described; where possible, request evidence of testing and mitigation for connection-tracking manipulation.
- End users and general IT operators: avoid colocating untrusted systems on the same NAT as critical services when practicable, and follow vendor guidance to apply updates; understand that the risk model changes when attackers can control a host inside the same NAT.
NatJack revives a longstanding but sometimes overlooked risk: NATs often encode assumptions about the behavior of hosts that share them. Stagg's work and the vendor CNA records show those assumptions can be dangerous in practice. Organizations cannot rely on a single patch or a single vendor bulletin to eliminate the threat; they must combine targeted fixes, architectural change, and encryption to blunt the techniques NatJack exposes.




