A research presented at Black Hat USA 2026 has identified NatJack, a new class of attacks against Network Address Translation (NAT) that does not rely on a specific software vulnerability, but rather on how different implementations manage connections and trust between systems sharing a NAT table. Tests conducted by researcher Malcolm Stagg found affected behaviors in Windows, Linux, and macOS, while two related flaws already have CVE identifiers.
The essentials of NatJack in 30 seconds
- NatJack combines four techniques to manipulate NAT implementations’ operation.
- It can enable TCP connection hijacking, DNS response manipulation, port discovery, and NAT table exhaustion.
- Tests revealed affected behaviors in independent code across Windows, Linux, and macOS.
- Two CVEs are already assigned: CVE-2026-56181 and CVE-2026-63913, with CVSS scores ranging from 7.2 to 9.6.
- No universal patch exists: cloud environments, Kubernetes, and multi-tenant setups require special attention.
NatJack has been developed over several years by Malcolm Stagg, researcher at SODIUM-24 and member of the Synack Red Team. The work was presented at Black Hat USA 2026 under the title Breaking Trust Boundaries: Exploiting Design Assumptions in Network Infrastructure.
The most relevant aspect for system administrators and infrastructure managers is that NatJack should not be seen simply as another router vulnerability.
NAT now appears within hypervisors, container hosts, Kubernetes, cloud gateways, firewalls, virtual bridges, and other network components. The same table can end up managing connections belonging to virtual machines or workloads with completely different trust levels.
This is where a design decision from the early days of the internet takes on new implications.
The issue isn’t NAT itself, but who shares its table
NAT was primarily created to allow multiple devices with private IP addresses to communicate with the internet using far fewer public IPv4 addresses.
To maintain communications, the device performing NAT needs to track which connection belongs to which system.
In simplified terms, when a machine with a private IP initiates a connection to the internet, NAT can modify the source address and port. It then keeps track of this mapping to ensure responses are routed back correctly.
A simplified example:
Server A
10.0.0.10:49152
│
▼
┌─────────────────────────┐
│ NAT Gateway │
│ │
│ 10.0.0.10:49152 │
│ ↕ │
│ 203.0.113.10:62001 │
└─────────────────────────┘
│
▼
InternetThis implementation requires maintaining states, port assignments, and connection tracking for proper operation.
On Linux, a key component is netfilter conntrack, which maintains information on active flows. Windows also has NAT mechanisms used, among others, by Hyper-V and virtualization technologies.
NatJack’s research starts with a simple question: what happens if one of the systems sharing this NAT infrastructure intentionally manipulates its behavior?
According to Synack, many implementations have historically assumed a certain level of trust among devices behind the same NAT table.
In today’s data centers, this assumption might no longer be valid.
Four different attack techniques
Stagg documented four techniques within NatJack, each targeting a different aspect of NAT’s operation.
The first aims to hijack active TCP connections.
The attacker seeks to manipulate NAT’s state information about an existing connection to interfere with another system’s traffic. The impact depends on the upper-level protocol: controlling a TCP flow doesn’t automatically break TLS encryption covering the session.
The second technique affects UDP-based DNS.
NatJack can leverage certain connection tracking features to attempt to introduce manipulated DNS responses. If successful and with no additional protections, a system might accept a fake response and resolve a domain to an attacker-controlled address.
The third technique allows identifying which external port NAT has assigned to another connection.
This information could be useful for narrowing down targets in subsequent attacks.
The fourth technique focuses on resource exhaustion.
NAT devices maintain a limited number of entries for tracking connections. An attacker capable of generating enough states could attempt to fill the NAT or conntrack table, making it difficult or impossible to establish new connections, leading to a denial-of-service.
| Technique | Objective |
|---|---|
| TCP hijacking | Interfere with or take control of active TCP connections |
| DNS poisoning | Inject false DNS responses |
| Port discovery | Identify ports assigned to other connections |
| NAT exhaustion | Saturate NAT or conntrack tables and disrupt connectivity |
Not all techniques will work on every device or have the same impact. Exploitability depends on implementation, configuration, topology, and attacker capabilities.
Hyper-V and netfilter already have CVEs
Coordinated disclosure has so far produced two public identifiers.
CVE-2026-56181 impacts Microsoft’s Windows NAT used in Hyper-V environments.
The second, CVE-2026-63913, relates to netfilter’s conntrack subsystem on Linux.
Synack places CVSS scores for these issues between 7.2 and 9.6, ranging from high severity to critical.
Having two CVEs across different platforms highlights the nature of the problem.
It’s not that Windows and Linux share the same flawed code—these implementations were developed independently.
The research also identified vulnerable behaviors in macOS.
For this reason, Synack considers NatJack to represent a class of attacks against specific NAT design assumptions, rather than a vulnerability confined to a single function.
Disclosure is ongoing, and additional alerts or CVEs may emerge.
Why Kubernetes and cloud environments deserve attention
The most interesting scenario for NatJack is likely not a home network, but multi-tenant infrastructures.
A modern server can run dozens or hundreds of virtual machines or containers.
┌──────────────┐
│ Virtual Machine A │──┐
└──────────────┘ │
│
┌──────────────┐ │ ┌─────────────┐
│ Virtual Machine B │──┼────▶│ Shared NAT │────▶ Internet
└──────────────┘ │ └─────────────┘
│
┌──────────────┐ │
│ Container X │──┘
└──────────────┘If all these systems belong to the same administrator and share similar trust levels, the risk profile differs.
However, in a public cloud, a shared Kubernetes platform, or services running third-party code, trusted and untrusted workloads can share common NAT components.
Synack recommends reviewing exposure in environments such as routers, firewalls, Docker, Kubernetes, Hyper-V, NAT gateways, virtual bridges, switches, and managed container and virtualization services.
This does not mean every Kubernetes cluster is vulnerable to a practical attack.
The critical question for administrators is:
Can a user-controlled workload share NAT infrastructure with sensitive systems?
If yes, NatJack warrants closer examination.
A conntrack table can also be a target resource
For Linux admins, the most relevant component is conntrack.
The kernel uses this subsystem to track connection info and offers parameters to query and limit the number of entries.
These include:
nf_conntrack_count
nf_conntrack_max
nf_conntrack_bucketsnf_conntrack_count indicates the current number of assigned entries, while nf_conntrack_max sets the maximum allowed.
An infrastructure where the connection count begins unexpectedly approaching the limit can experience issues establishing new flows.
NatJack can exploit this by deliberately exhausting the table.
For operations teams, this means conntrack metrics shouldn’t be viewed solely as performance indicators—they can also serve as a security signal.
Unusual connection spikes, atypical NAT table usage, or certain packet patterns may warrant further investigation.
No universal patch covers NatJack everywhere
This is probably the key factor that sets NatJack apart from conventional vulnerabilities.
There’s no single package that, once installed, can definitively resolve the issue across all infrastructures.
Synack notes that some updates already incorporate measures that hinder specific techniques. These include Linux kernel 6.6.142 and newer and FreeBSD 15.0 and newer.
However, these modifications do not change the fundamental design issues.
Each vendor will need to review their implementation and decide on changes related to port assignment, connection tracking, packet validation, and other related components.
The process might extend until coordinated disclosure concludes.
Therefore, architectural mitigations are as crucial as software updates.
What administrators can do
First, keep kernels, hypervisors, operating systems, firewalls, and gateways up to date. But NatJack also requires examining network architecture.
Synack recommends avoiding shared NAT infrastructure between workloads of different trust levels whenever possible.
Segmentation can be achieved by separating networks, gateways, or security domains to prevent untrusted containers or VMs from sharing NAT contexts with sensitive systems.
Encryption of internal traffic should also be considered.
While TLS is standard for internet communications, internal networks still sometimes operate without encryption, assuming inside the network suffices protection.
NatJack illustrates why this trust assumption can be problematic.
For DNS, Synack suggests considering DNSSEC and DNS encryption, along with mechanisms like IP Source Guard to mitigate certain impersonation scenarios.
Limiting network capabilities and privileges for containers and workloads that don’t need them is also advisable.
Finally, infrastructure teams should monitor NAT table usage, conntrack metrics, anomalous packet patterns, and unexpected connection behaviors.
The key takeaway from NatJack isn’t that NAT is broken and should be eliminated, but rather that NAT should not automatically be treated as a security boundary between untrusted loads.
This is especially important in 2026, where IPv4 sharing was designed in early internet days, but now NAT plays a role within hypervisors, container platforms, and clouds, where systems belonging to different users often operate on shared infrastructure.
NatJack demonstrates the need to revisit some of these early assumptions.
Frequently Asked Questions
What is NatJack?
NatJack is a class of attacks discovered by Malcolm Stagg that exploits certain behaviors and trust assumptions in NAT implementations. It includes techniques targeting TCP, DNS, port assignments, and NAT table availability.
Which systems are affected by NatJack?
Tests found vulnerable behaviors in implementations developed independently for Windows, Linux, and macOS. The specific risk depends on each environment’s implementation, configuration, and architecture.
What CVEs are related to NatJack?
So far, CVE-2026-56181 affecting Windows NAT in Hyper-V, and CVE-2026-63913 related to Linux’s netfilter conntrack, have been assigned. Disclosure is ongoing.
How can NatJack be mitigated?
Besides applying available updates, Synack recommends encrypting internal and external communications, separating trusted and untrusted workloads, avoiding shared NAT between different trust levels, securing DNS (e.g., DNSSEC, DNS encryption), limiting privileges, and monitoring NAT table and conntrack behavior.
Sources:
