NatJack: New Attack Class Can Hijack TCP Sessions and Spoof DNS Through NAT Manipulation
NatJack: New Attack Class Can Hijack TCP Sessions and Spoof DNS Through NAT Manipulation
A newly disclosed attack class called NatJack is challenging long-standing assumptions about the security of Network Address Translation (NAT).
Presented by security researcher Malcolm Stagg at Black Hat USA 2026, NatJack is not a single software vulnerability. Instead, it describes a class of attacks that abuses the way NAT implementations track connection state.
The research is particularly significant because NAT is deeply embedded in modern network infrastructure, from Linux firewalls and routers to virtualization platforms and enterprise gateways.
According to the research, NatJack techniques can be used to hijack active TCP connections, manipulate DNS responses, reveal mapped ports and exhaust NAT connection tables.
What Is NatJack?
NAT normally creates a translation between internal connections and external network traffic.
A simplified example looks like this:
Internal Host
192.168.1.20:50000
|
v
NAT
|
v
203.0.113.10:42001
|
v
Internet
The NAT device maintains state information so that return traffic can be associated with the correct internal connection.
NatJack targets assumptions made by this state-tracking mechanism.
The important point is that the attack does not depend on one specific vendor implementation. Researchers found similar behavioral weaknesses across independently developed NAT implementations.
Why NAT State Matters
Modern NAT devices maintain connection-tracking information.
Conceptually:
Internal connection
|
v
+-------------------+
| NAT state table |
+-------------------+
|
v
External connection
The device uses this state to determine where packets should go.
If an attacker can influence that state, the security boundary provided by NAT can become much weaker than administrators might expect.
This is especially relevant when multiple systems share the same NAT infrastructure.
TCP Session Hijacking
One of the NatJack techniques can interfere with an existing TCP connection.
Instead of simply attacking the destination server directly, the attacker attempts to manipulate the NAT state associated with the victim’s connection.
The conceptual flow is:
Victim
|
| TCP connection
v
NAT
|
v
Internet
Attacker
|
+----> Manipulates NAT state
If successful, traffic associated with the connection can potentially be redirected.
This is significant because the attacker does not necessarily need to compromise the destination server.
The NAT device itself becomes part of the attack surface.
DNS Spoofing Through NAT
Another particularly interesting technique involves DNS traffic.
DNS normally works through a request-and-response model:
Client
|
| DNS Query
v
DNS Resolver
|
| DNS Response
v
Client
NatJack can interfere with the NAT state associated with DNS communication.
This may allow an attacker to manipulate which response reaches the victim and potentially inject a forged DNS response.
This creates an important connection between NAT security and DNS security.
For a broader explanation of DNS spoofing, see the Netbe article on DNS Spoofing attacks.
Port Exposure
NAT is often viewed as a mechanism that hides internal addressing.
However, NatJack research also demonstrates techniques that can reveal information about NAT mappings and externally visible ports.
The security model therefore should not be:
Private IP + NAT = automatically protected
NAT is primarily a translation mechanism.
It should not be treated as a replacement for a properly configured firewall.
For Linux environments, Netbe’s guide to Linux firewall configuration with UFW, nftables and iptables provides a practical overview of the additional controls that should exist around network traffic.
NAT Table Exhaustion
NatJack also describes a denial-of-service technique involving NAT connection tables.
A simplified scenario:
Attacker
|
+---- Connection 1
+---- Connection 2
+---- Connection 3
+---- Connection 4
+---- ...
|
v
NAT connection table
|
v
Resource exhaustion
If the available connection-tracking resources are exhausted, legitimate clients may have difficulty establishing new connections.
This turns NAT state management into a potential availability concern.
Which Systems Are Affected?
The research is broader than a single router vendor.
Testing identified the underlying behavior across multiple independently developed NAT implementations, including environments based on Windows, Linux and macOS.
Two implementation-specific issues have received CVE identifiers so far:
- CVE-2026-56181 — Windows NAT used by Hyper-V.
- CVE-2026-63913 — Linux Netfilter conntrack.
The broader NatJack attack class, however, is not equivalent to these two CVEs.
The researchers describe it as a design-level issue involving assumptions about systems sharing NAT infrastructure.
Linux and Netfilter Conntrack
Linux systems commonly use connection tracking as part of their networking and firewall architecture.
Netfilter connection tracking maintains information about network flows.
For example:
Packet
|
v
Netfilter
|
v
Conntrack
|
+---- Existing flow
|
+---- New flow
This state is important for NAT and stateful firewall rules.
The Linux-specific NatJack issue demonstrates why connection tracking should be considered part of the security boundary rather than simply an internal implementation detail.
Administrators working with nftables should understand how stateful filtering and connection tracking interact.
Netbe’s guide to nftables firewall configuration on Linux provides a practical starting point.
Why Shared NAT Environments Are Important
NatJack becomes particularly interesting in environments where trusted and untrusted workloads share NAT infrastructure.
For example:
Shared NAT
|
+----------+----------+
| |
Trusted VM Untrusted VM
| |
+----------+----------+
|
Internet
If an attacker gains control over one system behind the same NAT boundary, the shared NAT state can become part of the attack surface.
This is especially relevant to:
- cloud environments,
- virtualization,
- containers,
- shared hosting,
- enterprise networks,
- laboratory environments,
- multi-tenant infrastructure.
NAT Is Not a Security Boundary by Itself
NatJack reinforces an important networking principle:
NAT should never be considered a complete security mechanism.
A properly secured environment should use multiple layers:
Internet
|
v
Firewall
|
v
NAT
|
v
Network Segmentation
|
v
Host Firewall
|
v
Application
NAT can provide address translation and connection handling.
A firewall provides explicit access-control policy.
Segmentation limits lateral movement.
Encryption protects traffic even if network-level manipulation occurs.
These mechanisms solve different problems.
Recommended Defensive Measures
There is no single configuration change that eliminates the broader NatJack attack class.
The research recommends a combination of defensive measures, including applying available implementation-specific security updates, separating untrusted workloads from sensitive systems, encrypting traffic and using controls such as IP Source Guard where appropriate.
1. Patch Affected Systems
Administrators should track vendor advisories for their specific NAT implementation.
For Linux systems, kernel updates should be evaluated according to the distribution and supported kernel versions.
The available Linux fix referenced by Synack includes kernel 6.6.142 and later, although patching does not eliminate every aspect of the broader design problem.
2. Separate Trusted and Untrusted Workloads
Avoid placing highly trusted systems and untrusted workloads behind the same shared NAT infrastructure whenever practical.
Instead:
Trusted workloads
|
Dedicated NAT
|
Internet
Untrusted workloads
|
Separate NAT
|
Internet
This reduces the opportunity for one compromised system to interfere with another system’s connection state.
3. Encrypt Internal Traffic
Encryption provides an additional layer of protection if network traffic is redirected.
For example:
Application
|
v
TLS / SSH / VPN
|
v
NAT
|
v
Internet
Even if an attacker can manipulate network routing or connection state, properly authenticated encryption can make meaningful session interception significantly harder.
4. Use Network Segmentation
Segmentation limits which systems can share the same network infrastructure.
Separate:
- servers,
- workstations,
- management systems,
- IoT devices,
- guest systems,
- untrusted workloads.
This approach also improves incident containment.
5. Use Firewall Policies
NAT should operate alongside explicit firewall rules.
A Linux firewall can restrict:
- inbound traffic,
- outbound traffic,
- forwarding,
- management access,
- inter-network communication.
For example:
Internet
|
v
[ Firewall ]
|
+---- Servers
|
+---- Users
|
+---- IoT
|
+---- Management
A firewall should enforce policy rather than relying on the fact that internal addresses are translated.
Monitoring NAT and Conntrack
Network administrators should monitor connection-tracking behavior where possible.
Useful indicators include:
- sudden growth in active connections,
- abnormal connection creation rates,
- unexpected NAT table exhaustion,
- repeated connection resets,
- unusual DNS behavior,
- unexpected traffic redirection.
On Linux, administrators can inspect connection tracking with tools appropriate to their distribution and firewall architecture.
For example:
sudo conntrack -L
and:
sudo nft list ruleset
The exact availability of conntrack depends on the installed packages and system configuration.
The Bigger Security Lesson
NatJack is important because it demonstrates how assumptions embedded in network infrastructure can become security weaknesses.
For decades, NAT implementations have relied on models where systems sharing the same NAT boundary are generally trusted.
Modern infrastructure is different.
A single NAT device may now serve:
- containers,
- virtual machines,
- cloud workloads,
- corporate endpoints,
- IoT devices,
- untrusted applications.
That makes the old trust model increasingly difficult to justify.
NAT Security in 2026
The NatJack research does not mean that NAT is suddenly obsolete.
NAT remains widely used and continues to serve important networking purposes.
The lesson is different:
NAT should be treated as part of the attack surface.
Network administrators should consider what happens if an attacker controls another system sharing the same NAT infrastructure.
That question becomes increasingly important in multi-tenant environments.
What Administrators Should Do Now
A practical response checklist is:
[ ] Identify NAT implementations in the environment
[ ] Check vendor security advisories
[ ] Apply available security updates
[ ] Identify shared NAT environments
[ ] Separate trusted and untrusted workloads
[ ] Review firewall policies
[ ] Monitor connection-tracking resources
[ ] Monitor unusual DNS behavior
[ ] Use TLS or other authenticated encryption
[ ] Review network segmentation
[ ] Consider IP Source Guard where supported
Organizations should also determine whether virtualization platforms, cloud environments or Linux gateways expose NAT state to workloads that should not be able to influence one another.
Final Thoughts
NatJack is a reminder that network infrastructure itself can contain security assumptions that remain invisible for years.
The newly disclosed attack class demonstrates how manipulation of NAT connection state can potentially affect TCP sessions, DNS responses, port visibility and connection availability.
For defenders, the most important takeaway is not to abandon NAT.
It is to stop treating NAT as a security boundary.
Modern network security requires layers:
NAT + firewall + segmentation + encryption + monitoring + timely patching.
As infrastructure becomes increasingly virtualized and multi-tenant, these assumptions will become even more important.
The security of a network does not depend only on whether packets can reach a destination.
It also depends on whether the infrastructure handling those packets can be trusted.
Related reading: Firewall in Linux: UFW, nftables and iptables · nftables Firewall Configuration · DNS Spoofing Attack
The cybersecurity industry is accelerating migration toward post-quantum cryptography (PQC) as organizations prepare for future quantum computing threats. Current public-key Czytaj dalej
Cisco FMC Zero-Day Is Being Actively Exploited Cisco has warned customers about a zero-day vulnerability in Firepower Management Center (FMC) Czytaj dalej
