Windows, Linux NAT bugs enable NatJack TCP hijacks

A newly disclosed attack class targeting network address translation (NAT) devices, dubbed NatJack, is upending long‑standing assumptions about how safely NAT shields internal hosts by enabling hijacked TCP sessions, spoofed DNS responses and forced denial‑of‑service on widely deployed platforms.^{[1][2][3][5][6][10]} Independent researcher and Synack Red Team member Malcolm Stagg detailed the work on stage at Black Hat USA 2026, following a multi‑year study of NAT connection‑tracking behavior across physical and virtual infrastructure.^{[1][2][3][6][7][12]} Two implementation‑specific bugs uncovered along the way have already been assigned CVEs — CVE‑2026‑56181 in Microsoft’s Windows NAT used by Hyper‑V and CVE‑2026‑63913 in the Linux netfilter conntrack subsystem — both rated high‑severity with CVSS v3 scores above 8.0.^{[2][3][6][8][10]}

NatJack exploits a design‑level weakness in how NAT engines track the state of connections, allowing an attacker who shares a NAT boundary with a victim to rewrite entries in the translation table and redirect traffic without touching the victim’s endpoint.^{[1][2][4][10]} Stagg’s techniques include TCP connection hijacking via an RFC 1337 TIME‑WAIT assassination trick that forces a legitimate flow into a closed state in just a handful of packets, then replaces the freed NAT mapping with one controlled by the attacker.^[1][4][10] Additional methods poison UDP‑based DNS responses passing through the NAT, discover which external ports have been assigned to other internal connections, and exhaust the NAT table outright to cut off connectivity for every device behind it.^{[1][2][3][4][5][6][10]}

According to Stagg’s testing, every NAT implementation evaluated — spanning Windows, Linux and macOS across routers, hypervisors, cloud gateways and container platforms — was vulnerable to at least some NatJack techniques, reinforcing that the issue stems from shared design assumptions rather than a single faulty product.^{[1][3][5][6][10]} Thirteen vendors were notified, covering 32 products and configurations documented in 95 individual reports, suggesting that exposure is broad wherever stateful NAT and connection tracking sit in front of workloads.^{[1][3][5][6][10]} For the Windows NAT origin‑validation flaw tracked as CVE‑2026‑56181, NVD describes a spoofing vulnerability on adjacent networks that could let an unauthenticated attacker manipulate NAT mappings and piggyback on other hosts’ traffic.^[8]

Successful NatJack exploitation typically requires an attacker to have privileged access to a system behind the same NAT as the victim, positioning them on an adjacent network rather than the public internet.^[2][10] That makes multi‑tenant environments such as cloud infrastructure, hosting providers, campus networks, office Wi‑Fi deployments and even shared home routers key risk zones, where an attacker who compromises one workload can pivot through the NAT to interfere with others.^{[1][2][3][5][6][10]} Unlike older Layer 2 hijacking techniques that depended on IP spoofing or broadcast‑domain access, NatJack works directly against the NAT table with no victim interaction beyond an active connection, broadening its appeal as soon as attackers gain a foothold.^{[1][4][6][10]}

There is no single patch for the broader NatJack attack class, and vendors are focusing first on discrete bugs like CVE‑2026‑56181 and CVE‑2026‑63913 while longer‑term design mitigations are discussed.^{[2][3][6][8][10]} Early advisories and industry coverage characterize NatJack as a warning shot about NAT’s trust model, stressing that conventional perimeter thinking may underestimate the risk of hostile code running inside shared translation domains.^{[1][3][5][6][10]} Public write‑ups so far do not describe confirmed in‑the‑wild exploitation, but the combination of high CVSS scores and ubiquitous NAT usage has pushed the issue onto incident response and architecture teams’ watch lists.^{[2][3][5][6][10]}

Defenders are being urged to treat NatJack as a prompt to revisit segmentation and trust boundaries, harden NAT configurations, and reduce opportunities for untrusted code to share translation infrastructure with sensitive workloads.^{[1][5][6][10]} Recommended measures in vendor and analyst guidance include encrypting application traffic with TLS end‑to‑end, adopting DNSSEC and encrypted DNS to blunt DNS poisoning, monitoring NAT tables for anomalies and exhaustion, disabling loose connection‑tracking modes where feasible, and isolating noisy or untrusted tenants from critical systems.^[1][5][10] Until more fundamental protocol‑level or architectural changes emerge, organizations that rely heavily on NAT — from cloud operators to enterprises and ISPs — will need to assume that adjacent attackers can target translation state itself and build detection and containment strategies accordingly.^{[1][3][5][6][10]}

References

1. NatJack at Black Hat: A new way to crack NAT’s trust gap
2. New NatJack Attacks Hijack TCP Sessions and Spoof DNS by Manipulating NAT Tables
3. Black Hat USA 2026 – Summary of Vendor …
4. Les exploits NatJack mettent les hypothèses de sécurité NAT à l’épreuve chez Black Hat – Illicit Trade FR
5. Neue Angriffsklasse trifft NAT-Netze weltweit
6. Security-Spezialisten warnen vor Designfehler in NAT-Implementierungen
7. Synack’s Malcolm Stagg to present ‘Breaking Trust …
8. CVE-2026-56181 – Windows Network Address Translation (NAT) Spoofing Vulnerability
10. NatJack exploits put NAT security assumptions to the test at Black Hat
12. Synack – blackhatusa