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 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
Black Hat USA 2026
This research was presented at Black Hat USA on August 6, 2026 as Breaking Trust Boundaries: Exploiting Design Assumptions in Network Infrastructure. Slides are available for download.
Attack Demonstrations
CVEs, Patches and Advisories
CVEs
- CVE-2026-56181: Microsoft Windows NAT (affecting Hyper-V in a downstream spoofing configuration)
- CVE-2026-56179: Microsoft Windows NAT (affecting Hyper-V in an upstream spoofing configuration). Note that this mitigation is disabled by default and must be enabled via a registry key.
- 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.
Advisories
- Amazon eero: Protecting eero customers from NatJack
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
Vendor Patch Status
The following table indicates last known vendor patch state, in a default configuration, last updated August 19, 2026. It does not necessarily indicate current status and does not include the complete list of affected vendors. Updates will be made to this matrix on a best-effort basis.
| Vendor | Product | Denial of Service | Port Disclosure | UDP DNS Hijack | TCP Downstream | TCP Upstream | Notes |
|---|---|---|---|---|---|---|---|
| Linux kernel | Netfilter | Initially rejected as "totally bogus" by the Linux kernel security team. However, CVE-2026-63913 was issued with a partial mitigation for the downstream spoofing TCP hijack, at the request of Microsoft, for kernel 6.6.142.1+:
|
|||||
| FreeBSD | pf | Rejected as a "resources are finite" report by the FreeBSD security team. However, hijack attacks in FreeBSD 15.0.0+ are highly mitigated due to an incidental patch. Prior versions are affected. | |||||
| OpenBSD | pf | OpenBSD pf team was helpful in identifying how their code is quite highly protected from the hijacking attacks by blocking the fast attack sequence and performing strict validation of RST packets. An attack is still theoretically possible, but time and complexity is very high. |
Network Infrastructure Devices
| Vendor | Product | Denial of Service | Port Disclosure | UDP DNS Hijack | TCP Downstream | TCP Upstream | Notes |
|---|---|---|---|---|---|---|---|
| Cisco | Firepower | Several Cisco mitigations are available. ISN randomization enabled by default + no "loose" mode provide partial mitigation. Data can be received over a hijacked connection but not sent. Complete protection will require customers setting up more mitigations and L3/L4 ACLs. | |||||
| Meraki | * | Several Cisco mitigations are available. Complete protection will require customers setting up these mitigations and L3/L4 ACLs. | |||||
| DD-WRT | Requires Linux Netfilter mitigations. | ||||||
| Nest WiFi Pro Router | Requires Linux Netfilter mitigations. | ||||||
| NETGEAR | Nighthawk | * | No update from vendor. | ||||
| OpenWRT | Requires Linux Netfilter mitigations. | ||||||
| SpaceX | Starlink Router | * | SpaceX does not recognize the hijacking attacks as a concern, stating "confidentiality guarantees come from the application layer rather than the network layer", but they "believe denial of service is a more relevant concern" and they're "looking into additional per-source connection limits. |
* Affected in a no-spoofing cross-subnet TCP hijack attack without the attack requiring an external attacker-controlled server.
Internet Sharing
| Vendor | Product | Denial of Service | Port Disclosure | UDP DNS Hijack | TCP Downstream | TCP Upstream | Notes |
|---|---|---|---|---|---|---|---|
| Apple | iOS Personal Hotspot | Apple's stated position is that these reports reflect "a known limitation of the transport layer rather than a vulnerability", that users should rely on TLS, and that "Internet Sharing is intended as a convenience feature for casually extending a connection to nearby devices, not as a hardened network gateway." They are considering the reports for a defense in depth. | |||||
| macOS Internet Sharing | |||||||
| Android Hotspot | Requires Linux Netfilter mitigations. Google accepted the UDP DNS hijacking reports as moderate severity but closed the TCP hijacking reports as "Not a Vulnerability", stating that their TLS requirements prevent useful TCP hijacking, but DNS could be targeted when "Private DNS" is disabled. | ||||||
| Microsoft | Windows Internet Connection Sharing (using legacy IPNAT) |
Reports under review. |
Virtualization
| Vendor | Product | Denial of Service | Port Disclosure | UDP DNS Hijack | TCP Downstream | TCP Upstream | Notes |
|---|---|---|---|---|---|---|---|
| Apple | Virtualization Framework (NAT using pf) |
Apple's stated position is that these reports reflect "a known limitation of the transport layer rather than a vulnerability", that users should rely on TLS, and that the "NAT path is a convenience mechanism for extending or sharing a connection among cooperating clients, not a hardened boundary". In the virtualization scenario, "the NAT attachment routes traffic for guests that are already configured and launched by the same local operator on a single host, so one guest influencing another's connection does not cross a meaningful trust boundary". They are considering the reports for a defense in depth. | |||||
| Linux | KVM | Requires Linux Netfilter mitigations. | |||||
| QEMU | |||||||
| Microsoft | Hyper-V (vSwitch using Windows NAT) |
Mitigations are available with CVE-2026-56181 (July 2026 patch update) and CVE-2026-56179 (August 2026 patch update):
|
Containerization
| Vendor | Product | Denial of Service | Port Disclosure | UDP DNS Hijack | TCP Downstream | TCP Upstream | Notes |
|---|---|---|---|---|---|---|---|
| Amazon | AWS EKS | Individual nodes do not perform NAT. Deployments could still be affected if they rely on other cloud infrastructure such as a NAT gateway or internet gateway, however. | |||||
| Docker | (Network bridge using Netfilter) | Requires Linux Netfilter mitigations. | |||||
| FreeBSD | Jails (using pf) |
Hijack attacks are highly mitigated in FreeBSD 15.0.0+. | |||||
| GKE + default CNI | Requires Linux Netfilter mitigations. Accepted as a vulnerability in a 3rd party library and $500 awarded. | ||||||
| GKE + Network Policy CNI | |||||||
| GKE + Dataplane V2 CNI | |||||||
| Kubernetes | MicroK8s + Calico CNI | Requires Linux Netfilter mitigations. | |||||
| MicroK8s + Flannel CNI | |||||||
| Microsoft | Azure AKS | Requires Linux Netfilter mitigations. Accepted by Microsoft at a moderate severity and resulted in Linux kernel CVE-2026-63913 for kernel 6.6.142.1+:
|
Public Cloud Infrastructure
| Vendor | Product | Denial of Service | Port Disclosure | UDP DNS Hijack | TCP Downstream | TCP Upstream | Notes |
|---|---|---|---|---|---|---|---|
| Amazon | AWS Lambda | Lambda containers run at a low privilege level without NET_RAW privileges, blocking the TCP hijacking attacks. |
|||||
| AWS NAT Gateway | AWS deployed mitigations on or before August 6, 2026 across all regions for NAT Gateway and Network Load Balancer (NLB). These mitigations appear to successfully prevent port detection and increase attack complexity by increasing the idle time requirement for hijacking attacks to over 5 minutes. Customers must still "[ensure] that their sockets are closed after the application's idle timeout expires" to prevent hijacking of any long-lived connections. | ||||||
| Cloud NAT | Some attacks prevented due to unique port assignment behavior. TCP hijacking attacks were possible. Accepted at $600. Google stated these are "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". Details currently redacted due to patching efforts in progress. | ||||||
| Cloud Run | * | Affected in a high-complexity cross-tenant attack. Reports marked as a duplicate of Cloud NAT reports. Details currently redacted due to patching efforts in progress. | |||||
| Microsoft | Azure Firewall (private IP) | Requires Linux Netfilter mitigations. Most reports are currently under review. The downstream attack was partially mitigated due to Azure Firewall disabling "loose" mode. Data could be received over a hijacked connection but not sent. The patch for CVE-2026-63913 now likely provides additional mitigations. | |||||
| Azure Firewall (public IP) | |||||||
| Azure Functions | * | Affected in a high-complexity cross-tenant attack. Details currently redacted due to patching efforts in progress. | |||||
| Azure NAT Gateway | Details currently redacted due to patching efforts in progress. |
* Affected in a high complexity attack between unique tenants.
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.
Synack Resources
Synack Security Research
Synack has partnered to make resources available for customers to help with mitigations. This includes an overview of the security research and a Research Report available as a free download.
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 TBD.
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 TBD.
Stay Informed
Sign Up for NatJack Resource Updates
Acknowledgements
Thank You
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?
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 9, 2026: Apple states that the Internet Sharing reports "[reflect] a known limitation of the transport layer rather than a vulnerability" and "where end-to-end security is in place, an attacker on the network path cannot decrypt the data exchanged between a client and a server". They also state "Internet Sharing is intended as a convenience feature for casually extending a connection to nearby devices, not as a hardened network gateway or a substitute for dedicated networking equipment. It does not attempt to isolate or fully protect clients from one another on the shared network." They are considering the report for a defense in depth, however.
- 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 15, 2026: Apple responds regarding the virtualization attack scenario that "while virtual machines provide strong execution and memory isolation, the virtualized NAT environment in this configuration operates similarly to a standard, shared physical local network" and that "modern security models assume the local network may be hostile. This is why we continue to rely on end to end encryption, such as TLS, to ensure data confidentiality and integrity".
- 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 28, 2026: SpaceX responds to reports, stating "confidentiality guarantees come from the application layer rather than the network layer", but they "believe denial of service is a more relevant concern" and they're "looking into additional per-source connection limits".
- July 30, 2026: Call with Microsoft engineering teams to discuss Azure NAT Gateway.
- August 1, 2026: Apple follows-up on the virtualization report that "while it does not change our assessment of the security impact, it's helpful context and something we'd like to consider as a defense-in-depth improvement" and states their position regarding NAT that "the NAT path is a convenience mechanism for extending or sharing a connection among cooperating clients, not a hardened boundary designed to isolate those clients from one another. In the virtualization scenario in particular, the NAT attachment routes traffic for guests that are already configured and launched by the same local operator on a single host, so one guest influencing another's connection does not cross a meaningful trust boundary." They are considering the reports for a defense in depth.
- 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.
- August 11, 2026: Microsoft releases a WinNAT patch affecting Hyper-V in an upstream spoofing configuration and publishes CVE-2026-56179 as moderate severity with no payment.
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.