natjack
A NEW ATTACK CLASS AGAINST NETWORK INFRASTRUCTURE DEVICES
What is NatJack?
NatJack is a newly developed network address translation (NAT) table manipulation attack class effective against most virtual and physical network infrastructure performing NAT. These attacks can be used to hijack an existing TCP connection traversing through the NAT, to intercept and maliciously alter UDP DNS responses, or to perform a denial-of-service attack.
The NatJack attack class affects an entire ecosystem of virtual and physical network infrastructure devices. Most modern network infrastructure relies on design assumptions that have remained unchallenged for decades since their original development. While these assumptions historically held under cooperative network environments, some no longer withstand adversarial conditions.
This is a systemic issue bigger than any one specific implementation and many unique NAT implementations have been found to be vulnerable.
Is my router vulnerable?
If you are a home user with a consumer-grade router, your router is very likely vulnerable, but you are most likely not at risk of an attack. For an attack to be performed, an untrusted privileged user would generally need be located behind your router. For most home users, this is not a common scenario or threat.
If you are a business or service provider, your routers, firewalls, containers, virtual machines, and other network infrastructure are likely vulnerable. This does not automatically mean you are at risk, but depending on your network setup, you could be at risk of an attack.
All tested routers and network infrastructure devices performing any form of network address translation have been found to be vulnerable to some or all of the NatJack attacks. Containerization systems including Docker and Kubernetes, and hypervisors including Hyper-V are affected by this attack class through virtual bridges and switches. Many public cloud services for containerization and virtualization are similarly affected.
In which scenarios is an attack most likely?
Corporate Networks
Where untrusted users or compromised devices, even those in a different subnet or VLAN, share the same router or firewall as trusted users.
Docker Containers
Running untrusted or compromised containers in a default networking configuration.
Kubernetes Deployments
Local or cloud deployments where a compromised pod is running on the same node as a trusted pod.
Virtual Machines
Running untrusted or compromised virtual machines in a default networking configuration.
Cloud Infrastructure
Cloud infrastructure including NAT gateways, internet gateways, firewalls, and serverless computing infrastructure can be affected when an attacker is positioned behind the NAT device.
What attacks are possible?
Many of the attacks have similar impact to an ARP spoofing attack, but bypass all existing mitigations. It is possible to perform attack variations in situations where an ARP attack would fail, including cases where the attacker and victim are positioned in completely different broadcast domains, including different subnets or VLANs, with only a shared NAT in common.
Vulnerability Description
Certain network address translation (NAT) implementations allow downstream attackers to manipulate NAT table state entries in a manner that enables TCP session hijacking through downstream IP spoofing. An attacker on the LAN side of the affected device can remove or replace NAT mappings associated with an active victim TCP connection and redirect traffic to an attacker-controlled system. Successful exploitation may allow the attacker to impersonate the victim to the upstream server, intercept valid TCP traffic, inject malicious application-layer data, terminate active sessions, or perform limited man-in-the-middle attacks against certain long-lived HTTP connections.
Vulnerability Description
Certain NAT implementations allow downstream attackers to manipulate NAT table state entries in a manner that enables TCP session hijacking through coordinated upstream IP spoofing. An attacker controlling both a downstream host and an upstream attacker-controlled server can remove or replace NAT mappings associated with an active victim TCP connection and redirect traffic away from the legitimate client. Successful exploitation may allow the attacker to impersonate the victim to the target server, intercept legitimate TCP traffic, inject malicious payloads, terminate active sessions, or perform limited man-in-the-middle attacks against certain persistent HTTP connections. Exploitation generally requires knowledge of the victim’s externally mapped ephemeral port, which may be obtainable through separate NAT information disclosure weaknesses.
Downstream spoofing (left) and upstream spoofing (right) variations
Vulnerability Description
Certain NAT implementations improperly protect UDP NAT state entries, allowing a downstream attacker to manipulate NAT table mappings associated with DNS traffic. An attacker on the LAN side of the affected device can remove or replace an existing NAT entry corresponding to a victim’s DNS query, causing legitimate DNS responses to be redirected to an attacker-controlled host. The attacker may then craft and transmit a spoofed DNS response to the victim, potentially enabling DNS hijacking, traffic redirection, denial of service, or interception of sensitive DNS information.
Victim port disclosure (left) and victim IP+port disclosure (right)
Vulnerability Description
Certain NAT implementations expose weaknesses in ephemeral port assignment and connection mapping behavior that allow a downstream attacker to infer active NAT mappings associated with out downstream clients. By leveraging predictable NAT port allocation behavior and crafted probing traffic, an attacker may determine the external ephemeral port associated with a victim connection and, under certain conditions, identify the corresponding internal client IP address. This information disclosure may facilitate subsequent attacks including TCP session hijacking and DNS response interception.
Vulnerability Description
Certain Network address translation (NAT) implementations are vulnerable to NAT table exhaustion attacks due to insufficient controls on connection state allocation and retention. An attacker positioned on the downstream (LAN) side of the affected device can generate large numbers of spoofed TCP or UDP flows that cause the NAT table to become saturated with persistent entries. Once the NAT table is exhausted, legitimate downstream clients may be unable to establish new outbound connections, resulting in a denial-of service condition affecting network and internet access.
Black Hat Briefing
This research was presented at Black Hat USA on August 6, 2026 as Breaking Trust Boundaries: Exploiting Design Assumptions in Network Infrastructure. Slides will be made available for download.
CVEs, Patches and Advisories
CVEs
- CVE-2026-56181: Microsoft Windows NAT (affecting Hyper-V in a downstream spoofing configuration)
- CVE-2026-63913: Linux Kernel Netfilter (fixing a code flaw and applying a mitigation for the downstream spoofing attack) applied in Linux kernel 7.1 and higher. This is not a complete fix but does increase attack complexity.
Patches
- FreeBSD incidental patch (unrelated to this research) from 2025 for Packet Filter which affects both downstream spoofing and upstream spoofing configurations, applied in FreeBSD 15.0.0 and higher. Code was pulled in from OpenBSD which has had this more secure behavior since 2016. Although not a complete fix, it makes most attacks much less practical. Thanks to sashan (OpenBSD) for pointing out this code.
AWS Public Statement
AWS investigated and deployed mitigations for reported behavior related to connection state management in services that perform port-level network address translation, NAT gateway and Network Load Balancer (NLB).
This research describes a scenario in which an actor with control of an EC2 instance within a VPC could send crafted TCP reset packets to manipulate NAT flow state, potentially enabling session disruption or interception of TCP and UDP connections traversing the NAT. The described scenario requires the actor to already control an instance within the same VPC as the targeted connection.
AWS has deployed updates across both services that strengthen connection state validation, including enhanced verification of TCP reset packets before modifying flow state. These mitigations are effective across all AWS Regions. Customer applications must follow TCP and UDP best practices, by ensuring that their sockets are closed after the application's idle timeout expires. No further customer action is required to inherit protection. Customers with high connection volumes and long-lived connections should monitor port utilization and may need to allocate additional Elastic IP addresses (NAT gateway) or expand target/subnet capacity (NLB) to accommodate longer port hold times introduced by this hardening [1][2].
The research also describes an information-disclosure technique in which an actor can infer in-use external NAT ports by observing responses to crafted SYN and ACK floods. This technique requires both an instance within the same VPC as the port disclosure sought and a cooperating external server capable of IP spoofing. The disclosed port information is limited to external NAT port numbers in use and does not reveal associated client IP:port pairs. AWS mitigations prevent the session manipulation techniques that would otherwise leverage this information.
We appreciate Malcolm Stagg's (SODIUM-24, LLC) commitment to coordinated disclosure and constructive collaboration throughout this process, and we encourage continued engagement from the security research community.
[1] https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateway-troubleshooting.html
[2] https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-troubleshooting.html
Social Media
#natjack
Until more vendor patches are available, mitigation strategies will be necessary for the forseeable future. Use #natjack on social media to share and track custom mitigation strategies, vendor security advisories, and patch releases.
How can I make my network more secure?
🔒 Encryption
- Use TLS (including HTTPS) everywhere, even on internal systems. This will completely prevent useful hijacking of connection data.
- Use DNS security such as DNSSEC to prevent spoofing of DNS responses. DNS encryption such as DNS over HTTPS or DNS over TLS is also recommended to prevent hijacking.
🐳 Containers and Virtualization
- Disable network access of untrusted containers and virtual machines when possible, or set them up in a private internal network.
- Run untrusted containers or virtual machines on their own isolated host machine.
- Avoid running containers as
root. - Drop the enabled-by-default
NET_RAWpermissions when running an untrusted container using--cap-drop=NET_RAW.
☸ Kubernetes
- Run untrusted kubernetes pods on a different node than trusted pods, in both local and cloud-based deployments.
- Avoid running kubernetes pods as
root. - Drop the enabled-by-default
NET_RAWpermissions usingsecurityContext.capabilities.drop.
☁️ Cloud
- Avoid placing untrusted and trusted VMs/containers behind the same NAT gateway, internet gateway, or cloud NAT.
- Use dedicated IPs for serverless computing rather than shared IPs, for better network isolation from other tenants.
🖧 Routers and Firewalls
- Enable IP source protection (IP Source Guard or similar) to prevent IP spoofing by client devices.
- Ensure untrusted users and devices are in a separate subnet/VLAN from trusted users and devices.
- Set up L3/L4 Access Control List (ACL) rules to specifically prevent untrusted devices from accessing any trusted hosts.
- Limit the maximum number of TCP/UDP connections per client to a reasonable limit, ideally under 10k or so.
- Disable any
nf_conntrack_tcp_looseorflags anyconnection modes which allow a connection to be added to the NAT table without a valid handshake. - Disable port preservation and endpoint-independent mapping if possible.
- Enable ISN randomization (
modulate stateor similar) when the option is available.
📊 Monitoring and Detection
Several common indicators of compromise (IoCs) include:
- NAT table full: A full, or nearly-full, NAT table.
- Port range flood: A flood of TCP or UDP packets from a downstream endpoint with a large range of source ports.
- IP spoofing: It may be possible to detect downstream IP spoofing, in some cases, by detecting the same IP address being used by two different physical addresses, or the same physical address sending packets from multiple IP addresses.
- Sequence of packets: Certain packet sequences from a downstream endpoint, such as
SYN,RSTorSYN,RST,SYN, sent sequentially with a consistent source and destination port. - TCP RST flood: A flood of
RSTpackets from an upstream or downstream endpoint where the sequence number is varied. - Invalid sequence numbers: TCP packets containing sequence numbers far outside their current TCP window.
- Reduced TTL: Packets may be sent with a reduced time-to-live (TTL) to reach only as far as the NAT device before being destroyed. This might be used by an attacker to prevent a standard endpoint response or to try to evade detection.
Additional Resources
NatJack White Paper (Free Download) Coming Soon!
A free white paper with more details about these attacks and potential mitigation strategies will be available for download. Please check back shortly.
NatJack Technical Report Coming Soon!
The NatJack Technical Report is a highly detailed technical document containing in depth attack details, pseudocode, test framework design, and attack modeling. Initial document release will focus mainly on Netfilter, with additional updates providing other vendor case studies. Release date TDB.
NatJack Defensive Toolkit Coming Soon!
The NatJack Defensive Toolkit will enable testing and characterization of network infrastructure in live and lab environments, with automatic report generation to help determine susceptibility to the various NatJack attack variations and provide mitigation recommendations. Release date TDB.
Stay Informed
Sign Up for NatJack Resource Updates
Acknowledgements
I would like to thank Yang et al. for their earlier research on NAT table manipulation attacks, which led to CVE-2023-30305 to CVE-2023-30314.
Thank you to all the vendors and CERT/CC for engaging with this research.
Special thanks to Vicki Stagg and Andrew Stagg for their unconditional support, and to Neil Graves for his help obtaining routers and advice for navigating a complex disclosure.
Shout out to a few of my colleagues for their support:
- Ryan Rutan and Synack, Inc.
- William “Phyr3wall” Wallace
- Mohammed “Moey” Jassim
Can I use the logo?
The NatJack name and logo are open-source visual assets designed to aid public awareness.
Media Kit
- Full logo files (svg): Download
- Square logo files (svg): Download
- Logo font: Orbitron by Matt McInerney
Logo and Media Usage Policy
- Permitted use: Media outlets, academic researchers, and independent security analysts are fully permitted to download, reproduce, and display the official NatJack logo in news articles, presentation slides, blog posts, and educational videos under Fair Use principles.
- Prohibited use: Commercial use including merchandise, paid marketing materials, or embedding the logo into proprietary scanning software is strictly prohibited without prior written authorization.
Disclosure Timeline
- April 30-May 6, 2026: Vulnerability reports disclosed to initial set of vendors and CERT/CC.
- May 4, 2026: Cisco acknowledges receipt of reports.
- May 6, 2026: AWS acknowledges receipt of reports and asks for an update on disclosure dates.
- May 8, 2026: Starlink acknowledges receipt of reports and asks for clarification.
- May 9, 2026: Docker acknowledges receipt of reports.
- May 20, 2026: CERT/CC case accepted (VU#268870).
- May 20, 2026: Greg Kroah-Hartman (Linux stable branch maintainer), on behalf of the Linux Kernel security team, states that the report has been previously rejected as being "totally bogus".
- May 20, 2026: Cross-tenant vulnerability in Azure Functions reported to Microsoft.
- May 21, 2026: Vulnerabilty reports disclosed to Netgear as an additional vendor.
- May 21, 2026: Netgear acknowledges receipt of reports.
- May 26, 2026: Cisco Meraki reports marked as triaged by bug bounty program, blocked on awaiting customer impact.
- May 27, 2026: FreeBSD reports their analysis has determined this is a "resources are finite" report rather than actual vulnerabilities.
- June 1, 2026: Vulnerabilty reports disclosed to OpenWRT as an additional vendor.
- June 5, 2026: Google closes the Android Hotspot TCP hijack issues as "Not a Vulnerability".
- June 7, 2026: OpenWRT reports that any Netfilter fixes would need to be ported back from the Linux kernel.
- June 9-15, 2026: Kubernetes bug bounty program closes the reports as "informative", stating that "the PoC is thorough and the technique is sound" but the Calico and Flannel CNIs are simply outside the scope of their program.
- June 10, 2026: Docker reports that their understanding is that this is a "vulnerability in Netfilter itself, which is used by Docker bridge network driver" and that "mitigating this issue requires a kernel update", as well as asking for disclosure timelines.
- June 11, 2026: Microsoft accepts the AKS reports as moderate severity, stating a fix will be available in Linux kernel v6.6.142.1+. The upstream attack is marked as a duplicate of downstream, but only the downstream attack is (partially) mitigated by the fix.
- June 16, 2026: Black Hat accepts this research for a briefing at Black Hat USA 2026 as Breaking Trust Boundaries: Exploiting Design Assumptions in Network Infrastructure.
- June 19, 2026: Linux Kernel commits a mitigation for the downstream spoofing attack on behalf of Microsoft for Azure AKS. This is not a complete fix but does significantly increase attack complexity.
- June 23, 2026: Microsoft requests additional clarification on the Hyper-V reports.
- June 26, 2026: Google accepts the Android Hotspot UDP DNS hijack issues as moderate severity.
- June 29, 2026: Google response on Android Hotspot issues indicate that their TLS requirements prevent useful TCP hijacking, but DNS could be targeted when "Private DNS" is disabled.
- June 30, 2026: Cisco reports their analysis determines the reports are "design-level NAT limitations rather than security vulnerabilities", and notes several mitigations which can be enabled to prevent many of the attacks (some of which may need to be manually enabled).
- July 1, 2026: Follow-up questions from Microsoft on the Hyper-V reports.
- July 6, 2026: Microsoft closes one of the Azure Firewall reports as "Not a Vulnerability" due to reproduction issues, and states it would be below the servicing threshold if it had reproduced due to adjacent network access and high attack complexity.
- July 6, 2026: Google accepts GKE reports.
- July 9, 2026: AWS states that they will publish an advisory to credit this research and may request patch verification for mitigations.
- July 9, 2026: Call with the Microsoft engineering team to discuss mitigations for the Hyper-V issues.
- July 14, 2026: Microsoft releases a WinNAT patch affecting Hyper-V in a downstream spoofing configuration and publishes CVE-2026-56181 as moderate severity with no payment. Microsoft states the moderate severity rating is because "the attack depends on ephemeral port allocations" (the PoC, however, can target the entire ephemeral port range in a matter of seconds).
- July 14, 2026: Google awards $500 for GKE reports, stating they require a fix in a 3rd party library.
- July 16, 2026: Microsoft states they have fixed the Azure Functions cross-tenant issue, but testing shows it has not yet been patched.
- July 19, 2026: Linux Kernel issues CVE-2026-63913 for their earlier mitigation.
- July 25, 2026: AWS pilots mitigations for early testing in a specific region.
- July 30, 2026: Call with Microsoft engineering teams to discuss Azure NAT Gateway.
- August 4, 2026: Google awards $600 for the Cloud NAT reports (now duplicating the Cloud Run reports as well), stating that the report shows "vulnerabilities with smaller security impact" affecting "Google Cloud products in Tier 1" and they applied a downgrade because it is "difficult to exploit in practice".
- August 4, 2026: AWS provides a draft of their public statement discussing mitigations to NAT Gateway and Network Load Balancer, now pushed to all regions.
- August 6, 2026: Black Hat USA briefing.
Was this helpful?
Docker and the Docker logo are trademarks or registered trademarks of Docker, Inc. in the United States and/or other countries. Docker, Inc. and other parties may also have trademark rights in other terms used herein.
Kubernetes is a registered trademark of The Linux Foundation in the United States and/or other countries, and is used pursuant to a license from The Linux Foundation.
Gear image is in the public domain by ProSmile (needpix.com). Virtualization image is in the public domain by OpenClipArt (freesvg.org) Cloud image is in the public domain by publicdomainvectors.org.