NatJack: The Same NAT Flaw Got Windows and Linux Patched — Cisco and Apple Call It a Feature
A Black Hat researcher tested 32 NAT implementations from 13 vendors and found every one vulnerable to some part of a four-technique attack class. Two vendors shipped CVEs and fixes. Two didn't.
On August 6, 2026, at Black Hat USA, Synack Red Team researcher Malcolm Stagg told the room that the trust model underneath nearly every NAT device on the planet is broken. Two vendors listened and shipped CVEs and fixes. Two told him it wasn't a vulnerability at all.
What Stagg actually tested
NatJack — the name Stagg and Synack gave the attack class — targets network address translation (NAT), the mechanism that lets multiple devices share one public IP. NAT's connection-tracking table is supposed to keep each device's traffic separate. Stagg's research, conducted over several years and disclosed jointly through Synack Red Team and his own research entity SODIUM-24, LLC, shows that devices sharing a NAT table can be made to interfere with one another — a design assumption baked into how NAT behavior was originally specified, not a single vendor's coding mistake.
The four NatJack techniques
All four rely on the same prerequisite: the attacker needs privileged access to a system sharing the victim's NAT — a co-tenant on a cloud gateway, another container on the same node, another user on the same shared VLAN. This isn't a drive-by internet attack; it's a lateral one.
| Technique | Mechanism | Effect |
|---|---|---|
| TCP session hijacking | A spoofed SYN followed by an invalid-sequence RST forces the victim's connection into CLOSE early; the RFC 1337 "TIME-WAIT Assassination" mechanism Stagg identified speeds this to a handful of packets instead of a full timeout. | The attacker's own flow claims the freed NAT mapping and traffic is redirected as if it were the victim's connection. |
| DNS response poisoning | Attacker intercepts and alters UDP DNS responses passing through the shared NAT. | Victim's DNS lookups resolve to attacker-controlled addresses without their knowledge. |
| Mapped-port discovery | Attacker probes the NAT to determine which external port it assigned to an active connection. | Feeds the other three techniques the targeting information they need. |
| NAT-table exhaustion | Attacker floods the table with spoofed flows until it fills. | Every device sharing that NAT loses the ability to open new connections — a denial of service. |
How the TCP hijack actually works
The Linux fix (CVE-2026-63913) describes the root cause precisely: conntrack's TCP state machine would force a connection to CLOSE on an RST with an invalid sequence number without checking that the RST was actually a valid reply in the correct direction. That's the exact bug NatJack's hijacking technique abuses.
NatJack TCP session hijack — mechanism
- Attacker shares the victim's NAT — Co-tenant on a cloud gateway, container, or shared VLAN
- Sends spoofed SYN + invalid-seq RST
- Conntrack force-closes the mapping — No direction check on the RST — the CVE-2026-63913 root cause
- RFC 1337 TIME-WAIT Assassination speeds closure
- Attacker's own flow claims the freed mapping
- Victim's traffic now routes through attacker's entry
Two CVEs came out of the disclosure
Of the 13 vendors Stagg notified, only Microsoft and the Linux kernel team assigned CVEs and shipped fixes.
Scores as of 2026-08-13live record →
| CVE | Component | CVSS 3.1 | CWE | EPSS | Status |
|---|---|---|---|---|---|
| CVE-2026-56181 | Windows NAT (used by Hyper-V) | 8.3 — AV:A/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H | CWE-346 (Origin Validation Error) | 0.24% (14.8th pct) | Patched — Windows 11 24H2/25H2/26H1, Server 2025 |
| CVE-2026-63913 | Linux kernel Netfilter conntrack | 8.2 — AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H | not assigned in the NVD record | 0.62% (46.4th pct) | Patched upstream, backported to 8 stable branches |
From disclosure to Black Hat
- Malcolm Stagg joins Synack Red TeamAfter his performance in a DARPA hardware bug bounty program.
- CVE-2026-56181 publishedWindows NAT origin-validation fix, ahead of public disclosure.
- CVE-2026-63913 publishedLinux Netfilter conntrack fix — patched upstream at Microsoft's request, for Azure Kubernetes Service.
- NatJack presented at Black Hat USACisco and Apple decline to treat their behavior as a vulnerability.
Patch it, or call it a feature
Even the vendors who patched didn't do so eagerly. Stagg told Network World the Linux kernel security team's first reaction to his report was that it was "totally bogus" — they fixed it anyway, reportedly after Microsoft asked for a fix to protect Azure Kubernetes Service. Cisco and Apple didn't move at all.
Two responses to the same root cause
- Microsoft — CVE-2026-56181, fixed builds shipped for Windows 11 24H2/25H2/26H1 and Windows Server 2025
- Linux kernel — CVE-2026-63913, backported to 8 stable branches (5.10.259 through 7.1)
- Linux security team's first reaction, per Stagg: "totally bogus" — fixed it regardless
- Cisco PSIRT: "these reports are design-level NAT limitations rather than security" [vulnerabilities] — points to existing Secure Firewall / IOS XE mitigations instead
- Apple Product Security: the behavior "reflects a known limitation" of the transport layer, since "modern security models assume the local network may be hostile"
I think it basically goes back to under-specification in some of the RFCs that just allow behaviors based on the assumption that you're in a network where the peers are trusted.
Where NatJack actually bites
Because the prerequisite is co-tenancy on a shared NAT, the environments that matter most are exactly the ones cloud and container platforms are built on:
- Shared Kubernetes nodes and pods behind the same cluster NAT
- Multi-tenant cloud NAT/egress gateways where unrelated customers' workloads share an outbound IP
- VDI and shared jump-host environments where multiple users' sessions traverse one NAT device
- Serverless platforms without dedicated per-function IPs
What to do about it now
- Apply the Windows and Linux updates that address CVE-2026-56181 and CVE-2026-63913.
- Encrypt traffic even on internal/local networks — Stagg notes an attacker can still hijack a connection but "can't send or receive any data over that connection unencrypted."
- Enable IP Source Guard or an equivalent anti-spoofing protection where the platform supports it.
- Segment untrusted workloads onto separate VLANs/subnets from trusted systems sharing the same NAT gateway.
- Cap connections per client (Stagg suggests roughly 10,000) to blunt table-exhaustion floods.
- Disable loose connection tracking, port preservation, and endpoint-independent mapping where not required.
- In containers/Kubernetes: restrict network access, avoid running as root, and drop default capabilities.
- Monitor for a full/near-full NAT table, floods across wide port ranges, duplicate IPs appearing in two places, and anomalous SYN/RST sequences.
What we don't know
CVE data as of 2026-08-13