Synack, which published the research alongside Stagg’s presentation, says NatJack covers four techniques: active TCP connection hijacking, DNS-response poisoning, discovery of NAT-assigned ports for other connections, and NAT-table exhaustion. The common condition is a hostile co-tenant that can send traffic through the same NAT state table as its target. That makes this most urgent for cloud, container, virtualized, campus, and multi-tenant environments—not the conventional “an attacker somewhere on the internet attacks a household router” scenario implied by some early coverage.
For Windows administrators, the immediate task is clear: install Microsoft’s July 2026 cumulative updates on affected systems that use Hyper-V NAT, then determine where shared NAT is part of a trust boundary. Patching matters, but it does not make shared NAT an isolation control.
The Windows CVE Is Patched, and Its Scope Is Specific
Microsoft’s advisory for CVE-2026-56181 describes an origin validation error in Windows Network Address Translation that could allow spoofing by an unauthorized attacker on an adjacent network. Microsoft assigned a CVSS 3.1 score of 8.3, rating it High, and credits Malcolm Stagg of SODIUM-24.
The fixed Windows versions recorded in Microsoft’s advisory and the National Vulnerability Database are:
- Windows 11, version 24H2: build 26100.8875 or later.
- Windows 11, version 25H2: build 26200.8875 or later.
- Windows 11, version 26H1: build 28000.2525 or later.
- Windows Server 2025, including Server Core: build 26100.33158 or later.
This is where the public framing needs correction. Microsoft’s CVE is about Windows NAT in Hyper-V, not a blanket finding that every Windows installation runs a vulnerable NAT service. A Windows 11 laptop that is not acting as a Hyper-V NAT host does not suddenly become a NatJack target merely because it uses NAT through its Wi-Fi router.
That distinction is operationally important. Hyper-V’s NAT infrastructure can underpin virtual switches, development labs, test networks, Windows containers, and locally virtualized workloads. An organization that uses those features to separate mutually untrusted tenants, applications, or developers should revisit that design. An organization using Hyper-V solely for a private lab with one trusted administrator faces a very different risk calculation.
Microsoft published CVE-2026-56181 on July 14—more than three weeks before Stagg’s Black Hat presentation on August 6. The conference was the public debut of the NatJack attack-class branding and broader research, not the first public disclosure of the Windows CVE. That timeline matters because it means the Windows patch was already available before attackers received the conference-level technical context.
Linux Confirms One Mechanism, Not the Entire Theory
The Linux CVE, CVE-2026-63913, is unusually useful because the kernel record states the bug’s mechanism in concrete terms. Linux netfilter conntrack could move an active TCP entry to the closed state after observing an invalid-sequence RST packet, without confirming that the packet arrived in the expected traffic direction or corresponded to an opposing SYN.
In plain language, that lets a crafted SYN-plus-RST sequence tear down NAT state more easily than it should. Once an active mapping is destroyed, an attacker may have a clearer route to manipulating the replacement state. This is a discrete implementation flaw in the TCP conntrack state machine—not proof that every NAT product shares the same code defect.
Kernel.org assigned the flaw a CVSS 3.1 score of 8.2. The affected-version data lists fixed stable releases including Linux 5.10.259, 5.15.210, 6.1.176, 6.6.143, 6.12.93, 6.18.35, 7.0.12, and mainline 7.1. Distribution status cannot be inferred from those upstream numbers alone: Ubuntu, Debian, Red Hat, SUSE, appliance vendors, and cloud images may backport the fix into kernels with different version strings. Administrators should check their vendor’s security tracker and installed package changelog rather than deciding they are safe or vulnerable from
uname -ralone.
There is a small but revealing mismatch in the public material. Synack’s August 6 announcement says Linux kernel 6.6.142 and later raises the exploitation bar, while kernel.org’s CVE record identifies 6.6.143 as the fixed stable release. When the primary kernel record and a researcher’s announcement differ by a point release, the kernel record should govern patch verification. Treat 6.6.143 as the relevant upstream fixed release unless your distribution explicitly documents a backport.
Ubuntu has already listed CVE-2026-63913 across a large number of supported kernel packages as needing evaluation or remediation, which is the normal downstream reality for a netfilter change. The CVE is not a “patch Linux once” event; it is a fleet inventory and vendor-advisory exercise.
Shared NAT Is the Exposure Test That Matters
NatJack challenges the assumption that a NAT boundary creates a meaningful security separation among its internal users. NAT was built to translate addresses and maintain state for return traffic. It was never designed as a tenant-isolation primitive.
The research claims testing across independently developed NAT implementations, including Windows, Linux, and macOS. That is significant evidence that the problem is broader than a single conntrack bug. It is not, however, proof that every router, firewall, cloud gateway, and container network behaves identically or is exploitable by every one of the four techniques.
The exposure test is therefore architectural:
- A hostile workload and a valuable workload must share a NAT state table or gateway.
- The attacker must be able to send the traffic necessary to influence or discover NAT mappings.
- The surrounding network must not stop spoofed or anomalous traffic before it reaches the NAT implementation.
- The service must have an active connection or availability dependency worth attacking.
This is why Kubernetes and cloud operators should pay attention first. A cluster can have sound namespace separation, separate VLANs, and restrictive east-west policy while still sending distinct workloads through a shared egress NAT device. VLAN boundaries do not inherently protect a shared NAT table above them. Likewise, a serverless platform that multiplexes untrusted customer functions through the same NAT gateway could create a higher-value target than a conventional office LAN.
The researcher’s demonstration does not mean that a tenant can magically cross every cloud provider’s isolation boundary. Major providers layer hypervisor, virtual-network, security-group, identity, and routing controls around NAT. But the finding does mean that shared egress infrastructure belongs in threat modeling rather than being treated as plumbing outside the security boundary.
Encryption Limits the Worst Case but Does Not Preserve Availability
TLS and other end-to-end encryption materially reduce the impact of a successful session-state attack. An attacker who takes over a NAT mapping cannot simply read or inject application data into a properly authenticated encrypted session. That is an important practical defense against credential theft and silent content modification.
Encryption does not prevent a malicious co-tenant from attempting to break connectivity, trigger connection resets, force costly reconnect loops, exhaust a finite NAT table, or poison an unprotected DNS lookup before the application establishes an encrypted session. Availability remains exposed, and DNS integrity still depends on how a resolver, client, and application validate answers.
That makes “we use HTTPS” an incomplete answer for infrastructure teams. Use TLS everywhere, including internally, but also ensure DNS uses authenticated resolvers and encrypted transports where practical; keep NAT tables from becoming a shared resource across untrusted groups; and set connection limits that prevent one workload from consuming the gateway’s available state.
What Windows and Infrastructure Teams Should Do Now
Start with the two known CVEs rather than trying to patch an attack class. Apply Microsoft’s July 2026 cumulative update to every Windows Server 2025 or Windows 11 host using Hyper-V NAT, and use the resulting OS build number—not merely the date of a Windows Update scan—to verify that the remediation installed. Update Linux hosts through the distribution’s security channel and confirm that the vendor has incorporated the CVE-2026-63913 fix.
Then review NAT placement. The highest-priority cases are shared Kubernetes nodes, container hosts, virtual-desktop platforms, developer virtualization networks, multi-tenant egress gateways, and any environment where an untrusted guest can share a NAT boundary with production or administrative traffic.
IP Source Guard or comparable anti-spoofing enforcement at the network edge is a sensible control where the switching and IP-addressing design supports it. Monitor NAT/conntrack utilization, abnormal creation rates, and unexpected TCP SYN or RST patterns. Set per-workload connection quotas. Remove permissive NAT modes, endpoint-independent mapping, or port-preservation behaviors if those features are unnecessary and the platform allows them to be changed safely.
Most importantly, stop using a common NAT gateway as evidence that two workloads are safely separated. The patches close identified bugs in Windows and Linux. NatJack’s lasting consequence is that shared NAT must now be treated as a resource that needs its own tenant boundary, capacity control, monitoring, and anti-spoofing policy.
References
- Primary source: Tech Times
Published: August 7, 2026 at 3:23 PM UTC
NatJack Attack Lets Any Co-Tenant Hijack Sessions: No Patch Closes Design Flaw
NAT vulnerability class NatJack, revealed at Black Hat USA 2026, lets co-tenants hijack TCP sessions, poison DNS, and deny connectivity across Windows, Linux, and macOS. The flaw is baked into RFCwww.techtimes.com - Related coverage: nvd.nist.gov
- Related coverage: nvd.nist.gov
- Related coverage: cert.ssi.gouv.fr
Multiples vulnérabilités dans le noyau Linux d'Ubuntu - CERT-FR
cert.ssi.gouv.fr
- Related coverage: scribd.com
- Related coverage: msrc.microsoft.com
Categories | Microsoft Security Response Center
The Microsoft Security Response Center is part of the defender community and on the front line of security response evolution. For over twenty years, we have been engaged with security researchers working to protect customers and the broader ecosystem.msrc.microsoft.com - Related coverage: community.adobe.com
- Related coverage: msrc.microsoft.com
Blog MSRC | Microsoft Security Response Center
Microsoft Security Response Center Blogmsrc.microsoft.com