# NatJack: NAT Connection-Tracking Manipulation Attacks Hijack TCP Sessions Across Windows, Linux, and macOS (CVE-2026-56181, CVE-2026-63913)

> Independent researcher Malcolm Stagg (Synack Red Team) disclosed NatJack at Black Hat USA 2026, a class of attacks that manipulates Network Address Translation (NAT) connection-tracking state to hijack active TCP sessions, poison DNS responses, enumerate NAT-assigned connection ports, and exhaust NAT tables for denial of service. Every one of 32 tested products/configurations from 13 notified vendors was vulnerable to some or all techniques; CVE-2026-56181 covers Windows NAT/Hyper-V and CVE-2026-63913 covers Linux Netfilter conntrack. No public evidence of in-the-wild exploitation as of disclosure.

- **Published:** 2026-08-07T00:00:00Z
- **Last reviewed:** 2026-08-07T11:41:31.405Z
- **Canonical:** https://intel.threadlinqs.com/threat/TL-2026-1927
- **ID:** TL-2026-1927
- **Severity:** HIGH (CVSS 8.3)
- **Category:** VULNERABILITY
- **Status:** ACTIVE
- **Detections:** 9 · **IOCs:** 12 (full data via the Threadlinqs MCP server — Purple tier)
- **CVEs:** CVE-2026-56181, CVE-2026-63913

## Description

NatJack is a research-disclosed class of network-infrastructure attacks, presented by Malcolm Stagg (independent researcher and Synack Red Team member) in the Black Hat USA 2026 talk 'Breaking Trust Boundaries: Exploiting Design Assumptions in Network Infrastructure' (Oceanside D, August 6, 2026, 10:15-10:45am PT). The research is the product of roughly three years of independent investigation and targets a decades-old design assumption baked into NAT/connection-tracking implementations: that devices sharing a NAT table can trust one another. That assumption held while networks operated cooperatively but breaks down under adversarial conditions, letting an attacker who merely shares a NAT boundary with a victim (adjacent-network position, no IP spoofing or broadcast-domain access required in the classic Layer 2 sense) manipulate connection-tracking state directly.

Stagg documents four distinct techniques: (1) TCP connection hijacking, which forces a victim's tracked connection into a closed state using spoofed packets and then substitutes the resulting NAT table entry with one pointing at the attacker, leveraging the RFC 1337 TIME-WAIT Assassination mechanism to complete the takeover in a minimal number of packets; (2) DNS response poisoning, which intercepts and modifies UDP DNS responses traversing the NAT to silently redirect victim lookups; (3) NAT table exhaustion, which floods the shared NAT/conntrack table until it fills, breaking connectivity for every device sharing that NAT (denial of service); and (4) connection port identification, which determines which port a NAT assigned to an active connection and underpins the other three techniques. Because the manipulation happens at Layers 3-4 inside the NAT/connection-tracking state machine, it bypasses Layer 2 isolation controls such as VLAN segmentation and switch port isolation that defenders typically rely on to separate mutually-untrusting hosts. Stagg has described discovering the flaw accidentally, noting he began 'noticing that I was sometimes getting responses that didn't correspond to the packets that I was sending.'

Two CVEs were assigned as of disclosure. CVE-2026-56181 (CVSS 3.1: 8.3, AV:A/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H, CWE-346 Origin Validation Error) affects Windows NAT in Hyper-V: an origin-validation failure lets an unauthorized attacker on an adjacent network spoof traffic into the NAT/Hyper-V connection-tracking path. It is fixed in Windows 11 24H2 (10.0.26100.8875+), 25H2 (10.0.26200.8875+), 26H1 (10.0.28000.2525+), and Windows Server 2025 (10.0.26100.33158+). CVE-2026-63913 (CVSS 3.1: 8.2, AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H) affects the Linux kernel's Netfilter conntrack TCP state machine (net/netfilter/nf_conntrack_proto_tcp.c): the module fails to validate packet direction when processing RST packets, letting a crafted RST with an invalid sequence number force a tracked connection into CLOSE state prematurely and open its NAT slot for hijack or reuse. The flaw has existed since kernel 2.6.15 and is fixed in 5.10.259+, 5.15.210+, 6.1.176+, 6.6.143+, 6.12.93+, 6.18.35+, 7.0.12+, and 7.1+; the fix was expedited in part at Microsoft Azure Kubernetes Service's request given AKS's reliance on Linux conntrack for pod/service networking.

Across the 95 vulnerability reports Stagg filed with 13 vendors covering 32 products/configurations, every tested NAT implementation was vulnerable to at least one NatJack technique, spanning Windows, Linux, and macOS. Not every vendor accepted the CVE-worthy framing: Cisco PSIRT classified the findings against Secure Firewall and IOS XE as 'design-level NAT limitations rather than security vulnerabilities' while still publishing documented mitigations for both product lines, and Apple stated the behavior 'reflects a known limitation of the transport layer rather than a vulnerability,' with no CVE assigned to macOS as of disclosure. FreeBSD's NAT stack is fixed as of FreeBSD 15.0. Synack CTO Mark Kuhr framed the research's significance as showing 'why effective security testing must challenge long-held design assumptions, not only search for familiar software flaws.'

Synack's published mitigation guidance emphasizes detection over pure patching given the mixed vendor response: monitor for full or near-full NAT/conntrack tables, wide-range packet floods, duplicate source IPs observed from two network locations behind the same NAT, and anomalous SYN/RST sequences; enable IP Source Guard to block spoofed-source packets; segment untrusted traffic away from trusted traffic rather than sharing a NAT boundary across trust zones; cap per-client concurrent connections (Synack suggests roughly 10,000) to blunt table-exhaustion DoS; disable loose connection-tracking modes, port preservation, and endpoint-independent mapping where not required; restrict container/Kubernetes workloads' shared NAT-gateway access and isolate cloud workloads per NAT gateway; and rely on end-to-end TLS so that on-path NAT-table manipulation cannot silently alter application data even if session hijack succeeds.

## MITRE ATT&CK

- T1590 Gather Victim Network Information
- T1590.005 Gather Victim Network Information: IP Addresses
- T1046 Network Service Discovery
- T1599 Network Boundary Bridging
- T1599.001 Network Boundary Bridging: Network Address Translation Traversal
- T1557 Adversary-in-the-Middle
- T1565.002 Data Manipulation: Transmitted Data Manipulation
- T1499.002 Endpoint Denial of Service: Service Exhaustion Flood
- T1040 Network Sniffing
- T1018 Remote System Discovery
- T1499.001 Endpoint Denial of Service: OS Exhaustion Flood
- T1499.004 Endpoint Denial of Service: Application or System Exploitation

## Sources

- [NatJack at Black Hat: A new way to crack NAT's trust gap](https://www.networkworld.com/article/4206287/natjack-exploits-put-nat-security-assumptions-to-the-test-at-black-hat.html)
- [Synack Red Team at Black Hat 2026: Malcolm Stagg](https://www.synack.com/blog/malcolm-stagg-black-hat-2026/)
- [CVE-2026-56181 Detail](https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2026-56181)
- [CVE-2026-63913 Detail](https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2026-63913)
- [New NatJack Research Exposes Design Weaknesses Across Major NAT Implementations](https://www.streetinsider.com/Globe+Newswire/New+NatJack+Research+Exposes+Design+Weaknesses+Across+Major+NAT+Implementations/26882281.html)
- [New NatJack Research Exposes Design Weaknesses Across Major NAT Implementations](https://itbusinessnet.com/2026/08/new-natjack-research-exposes-design-weaknesses-across-major-nat-implementations/)
- [CISA Known Exploited Vulnerabilities Catalog (checked — CVE-2026-56181 / CVE-2026-63913 not listed as of Aug 6 2026 release)](https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json)
- [CVE-2026-56181 — Microsoft Security Response Center Update Guide](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-56181)

## Full data

Detection queries (Splunk SPL / Microsoft KQL / Sigma) and IOC values require the Threadlinqs MCP server (Purple tier): https://intel.threadlinqs.com/mcp

Canonical: https://intel.threadlinqs.com/threat/TL-2026-1927