Researcher Malcolm Stagg disclosed NatJack at Black Hat USA 2026, a new attack class that manipulates NAT connection tracking tables to enable TCP connection hijacking, DNS response poisoning, denial of service, and port identification — all without requiring Layer 2 access or victim interaction beyond sharing a NAT boundary. Testing covered 32 products across 95 configurations, and every implementation was vulnerable to at least some techniques. Thirteen vendors were notified with mixed results: the Linux kernel was eventually patched (CVE-2026-63913) at Microsoft's request for Azure Kubernetes Service, and Windows NAT in Hyper-V received CVE-2026-56181, while Cisco and Apple declined to classify the findings as vulnerabilities. Mitigations include monitoring NAT table saturation, enabling IP Source Guard, segmenting untrusted traffic, disabling loose connection tracking, and isolating cloud workloads.
Questions this post answers
What is the NatJack attack and how does it work against NAT infrastructure?
NatJack is an attack class that manipulates NAT connection tracking tables to hijack TCP connections, poison DNS responses, cause denial of service, and identify active connection ports. An attacker sharing a NAT boundary with a victim can execute these attacks without IP spoofing, Layer 2 broadcast domain access, or any victim action beyond having an active connection. Every tested implementation across 32 products was vulnerable to at least some techniques. Network engineers auditing shared NAT environments track NatJack coverage and vendor patch status on daily.dev.
What CVEs were assigned for the NatJack NAT vulnerabilities in Linux and Windows?
The Linux kernel received CVE-2026-63913, patched at Microsoft's request to support Azure Kubernetes Service after the kernel security team initially dismissed the report as 'totally bogus.' Microsoft's Windows NAT vulnerability affecting Hyper-V was assigned CVE-2026-56181. Cisco and Apple declined to issue CVEs, classifying the findings as design-level limitations rather than security vulnerabilities. Teams running Hyper-V or AKS workloads can follow NatJack patch rollouts on daily.dev.
How can I mitigate NatJack NAT attacks without a full vendor patch?
Key mitigations include enabling IP Source Guard to block spoofed packets, placing untrusted users on separate subnets with per-client connection caps under 10,000, disabling loose connection tracking and endpoint-independent mapping, restricting network access for untrusted containers and Kubernetes workloads, and keeping untrusted and trusted workloads off the same NAT gateway. Monitoring for a full NAT table and anomalous SYN or RST sequences also helps detect active exploitation. Infrastructure teams hardening shared NAT environments find the latest defensive guidance on daily.dev.