SURIQ
The precondition that makes NatJack work is not the exotic part. It is the part most operators already meet without thinking about it. Any time two workloads sit behind one shared network address translation (NAT) layer, one of them can now reach into the other's live connections. That is the default arrangement for containers on a bridge network, virtual machines behind a hypervisor, and cloud instances routed out through one gateway.
NatJack is the name Malcolm Stagg, an independent researcher, gave to a set of attacks he presented at Black Hat USA 2026. Instead of sitting on the wire between two hosts, the attacker edits the connection-tracking state that the shared NAT keeps. From that position, one host can hijack a neighbor's active TCP session, forge its DNS answers, reveal its mapped ports, or fill the table until nobody else can open a connection. Two CVEs carry the concrete, patchable pieces: one in Windows, one in the Linux kernel.
How NatJack rewrites a connection you do not own
A NAT device keeps a table (on Linux, the conntrack table maintained by netfilter) that maps every internal connection to an external address and port. That table is trusted shared state. Stagg's work shows that a process with privileged access to one host behind the NAT can alter entries that belong to a different host behind the same NAT.
The four techniques follow from that single ability. Replacing a victim's NAT mapping reroutes the traffic of an established TCP session to the attacker. Intercepting a victim's outbound DNS query lets the attacker take the genuine answer and return a forged one, which is DNS spoofing that never touches the victim's resolver. A third path reveals which external ports the NAT has mapped for a neighbor. A fourth floods the table with forged flows until real clients can no longer claim an entry, a denial of service aimed at the NAT itself.
Stagg reported the same class of weakness across independently built NAT implementations and demonstrated working proof-of-concept code. This is disclosed research, not a report of exploitation in the wild. A demonstrated technique with public detail rarely stays theoretical for long, though, so the clock on patching starts now.
The two bugs are not the same problem
It is tempting to file both CVEs under one NAT-bug heading and patch them together. Read the vectors and they pull apart.
CVE-2026-56181 in Windows NAT is the adjacent-hijack primitive. Microsoft scored it 8.3 with an adjacent attack vector and a changed scope (CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H), meaning an attacker on the adjacent network can break past the NAT boundary and hit confidentiality, integrity, and availability at once. This is the one that maps to session hijack and DNS spoofing. It is fixed in the August builds of Windows 11 (versions 24H2, 25H2, and 26H1) and Windows Server 2025.
CVE-2026-63913 in the Linux kernel is narrower and, on paper, more reachable. The fix stops conntrack from dropping a tracked TCP connection to CLOSE when it sees a reset whose sequence number is wrong and whose direction was never verified. Scored 8.2 with a network attack vector but only low integrity and high availability impact (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H), it is a teardown weakness: a crafted reset can knock tracked sessions down, not silently take them over. Patch both, but do not assume the Linux update closes the hijack path or that the Windows update closes the teardown path.
The Linux fix landed in stable kernels 5.10.259, 5.15.210, 6.1.176, and 6.6.143 and later. The touched file is net/netfilter/nf_conntrack_proto_tcp.c, so a distribution kernel that has backported that commit is covered even when its version string looks older. Check the changelog, not just the number.
Why "behind the same NAT" describes most of your infrastructure
The mental model that keeps this from being everyone's problem is that the attacker has to already be inside your NAT, and that surely they are not. In 2026 they often are. Containers on a default Docker bridge share one NAT. Virtual machines behind a hypervisor's built-in NAT, which is the exact territory of the Windows bug, share one NAT. Cloud instances behind a single NAT gateway share one NAT. Carrier-grade NAT puts thousands of unrelated subscribers behind one. In each case the workloads distrust each other yet share the connection-tracking state that NatJack manipulates.
So the real precondition is not "on the network path." It is "one neighbor is already compromised." A single popped container, a single tenant that got in, a single instance running attacker code becomes a spot from which to hijack the sessions and redirect the DNS of everything else on that NAT. That is lateral movement that leaves the wire untouched and does not announce itself as ARP spoofing or a rogue gateway. We have watched the same "one foothold, then reach the neighbors" pattern in Linux container escapes and in cross-tenant virtualization flaws. NatJack adds a network-layer version that needs no escape at all, just a seat behind the shared table.
How would you know? Detecting NAT-table tampering
You cannot see this in a file scan, and an endpoint agent watching processes will miss it, because nothing malicious runs on the victim. The evidence lives in network and host telemetry. Watch for TCP sessions that reset or reroute with no application-level cause, DNS answers that do not match what your own resolver's upstream returned, conntrack tables filling far past their baseline, and unexpected state transitions on tracked connections. The DNS-hijack pattern we covered on shared hotel networks is the same shape of attack from a different vantage point, and the same detection idea applies: compare the answer a client got against the one it should have gotten.
This is a hunt, not a patch. It belongs with the rest of your east-west threat hunting: map which workloads share a NAT, correlate the network anomalies against that map, and treat one neighbor's odd connection behavior as a signal about the whole shared segment rather than a single host.
Patch the two kernels, then treat shared NAT as hostile
The immediate work is small and specific. Update Windows 11 and Windows Server 2025 to the August builds for CVE-2026-56181. Move Linux hosts to a kernel that carries the CVE-2026-63913 fix (5.10.259, 5.15.210, 6.1.176, 6.6.143, or later, or a distribution kernel with the backport). Neither patch is optional on a machine that acts as a NAT for workloads you do not fully trust.
The lasting work is architectural, because Stagg is explicit that no single patch covers the class. Stop treating internal traffic as safe by default. Encrypt east-west connections so a hijacked session yields ciphertext, and authenticate DNS so a forged answer fails validation. Where the platform offers it, IP Source Guard blocks the spoofed source addresses these techniques depend on. Above all, stop putting untrusted and trusted workloads behind one NAT and calling the shared table a boundary. It never was one. NatJack just made the point in public.
| Attribute | CVE-2026-56181 | CVE-2026-63913 |
|---|---|---|
| Component | Windows NAT | Linux kernel netfilter conntrack |
| Flaw type | Origin-validation error (CWE-346) | Forced TCP CLOSE on an invalid-sequence reset with no direction check |
| What it enables | Adjacent spoofing and live session hijack | Premature teardown of tracked TCP connections |
| CVSS | 8.3 (AV:A, scope changed, full CIA impact) | 8.2 (AV:N, low integrity, high availability impact) |
| Affected | Windows 11 24H2, 25H2, 26H1; Windows Server 2025 | Linux kernels from 2.6.15 up to the fixed builds |
| Fixed in | August 2026 Windows builds | 5.10.259, 5.15.210, 6.1.176, 6.6.143 and later |