Network Address Translation is everywhere.
Home routers, Linux firewalls, cloud environments, virtualization platforms and container infrastructure all depend on NAT and connection tracking.
For years, NAT has often been perceived as an additional layer of protection because internal addresses are not directly exposed to the Internet.
A newly disclosed attack class called NatJack shows why this assumption deserves another look.
The research presented at Black Hat USA 2026 focuses on weaknesses in NAT connection-state handling and demonstrates potential attacks involving TCP sessions, DNS traffic, NAT mappings and connection-table exhaustion.
The important takeaway for developers and infrastructure engineers is simple:
NAT is a networking mechanism, not a complete security boundary.
How NAT Connection Tracking Works
Consider a simple Linux gateway:
Client
192.168.1.10:50000
|
v
Linux Gateway
|
| NAT
v
203.0.113.10:42001
|
v
Internet
The gateway maintains state describing the connection.
Conceptually:
Internal:
192.168.1.10:50000
External:
203.0.113.10:42001
When return traffic arrives, the NAT implementation uses this state to determine where the packet should go.
This state is critical.
It is also part of the attack surface.
Where NatJack Fits
NatJack focuses on assumptions made by NAT implementations when handling connection state.
The research is interesting because it is not simply another vulnerability in one router.
Instead, it describes a broader class of attacks that can affect independently developed NAT implementations under specific conditions.
Potential consequences include:
- TCP session hijacking
- DNS response manipulation
- NAT port discovery
- connection-table exhaustion
- disruption of existing connections
The full technical analysis is available here:
Linux Developers Should Pay Attention
Linux networking commonly relies on Netfilter and connection tracking.
A simplified architecture looks like:
Packet
|
v
Netfilter
|
v
Conntrack
|
+---- Existing flow
|
+---- New flow
Conntrack is involved in:
- stateful firewalling
- NAT
- connection management
- packet classification
This means that a weakness in connection-state handling can have consequences beyond simple packet forwarding.
For Linux developers and administrators, it is therefore important to understand that firewall state and NAT state are closely connected.
What About Containers?
Container environments make this particularly relevant.
A typical deployment might look like:
Internet
|
v
Linux Host
|
NAT
|
+-----------+-----------+
| | |
App A App B App C
Multiple applications may share networking infrastructure.
If an attacker gains control over one workload, the security question becomes:
What other workloads share the same NAT and connection-tracking state?
This is an important architectural question for:
- Docker deployments
- Kubernetes clusters
- CI/CD infrastructure
- cloud workloads
- multi-tenant applications
NAT Should Not Replace Segmentation
One common architectural mistake is assuming that NAT automatically separates systems.
It does not.
Consider:
Internet
|
v
NAT Gateway
|
+---- Server
|
+---- Database
|
+---- Developer Workstation
|
+---- Untrusted Workload
All of these systems may technically be behind the same NAT boundary.
A better design separates security zones:
Firewall
|
+-----------+-----------+
| | |
Servers Users Untrusted
| | |
Zone A Zone B Zone C
NAT can still be used, but it should not be the only security control.
DNS Is Another Important Part
NatJack is particularly interesting from a DNS security perspective.
A standard DNS exchange is:
Application
|
v
DNS Resolver
|
v
DNS Response
If network state can be manipulated, DNS responses may become part of the attack path.
A forged DNS response could potentially redirect an application toward an unintended destination.
This is why developers should not assume:
DNS response = automatically trustworthy
Applications should use authenticated and encrypted protocols where appropriate.
For a deeper look at DNS spoofing attacks and defensive techniques, see:
https://netbe.pl/atak-dns-spoofing-co-to-jest-na-czym-polega-jak-sie-bronic-i-zabezpieczyc/
Monitoring Conntrack
Infrastructure teams should monitor connection-tracking behavior.
On Linux, administrators can inspect current conntrack entries with:
sudo conntrack -L
Firewall state can be reviewed with:
sudo nft list ruleset
Depending on the environment, useful indicators include:
Connection count
TCP resets
SYN rate
NAT table utilization
DNS anomalies
Connection failures
A sudden increase in connection creation can indicate:
- application problems
- scanning
- abuse
- denial-of-service activity
- misconfiguration
Monitoring these metrics gives defenders much better visibility.
Connection Table Exhaustion
NAT devices have finite resources.
An attacker generating large numbers of connections may consume those resources.
Conceptually:
Normal:
NAT Table
[■■■■■■□□□□□□]
Attack:
NAT Table
[■■■■■■■■■■■■]
Once resources are exhausted, legitimate clients can start experiencing connection failures.
This makes resource monitoring an important part of network security.
What Developers Can Do
Developers may not control the NAT gateway, but application design can still reduce the impact of network manipulation.
Use TLS
Do not rely on network location for trust.
Use authenticated encryption:
Application
|
TLS
|
v
Network
Avoid Hard-Coded Trust in DNS
DNS should be treated as infrastructure rather than an unquestionable source of application identity.
Where security matters, validate the destination through cryptographic mechanisms.
Design for Network Failure
Applications should handle:
- connection resets
- DNS failures
- timeouts
- retries
- temporary network unavailability
This is especially important for distributed systems.
Use Short-Lived Credentials
If network-level manipulation occurs, long-lived credentials increase the potential impact.
Short-lived tokens and proper authentication reduce the blast radius.
What Infrastructure Teams Should Do
A practical checklist:
[ ] Patch Linux kernels and network appliances
[ ] Review NAT implementations
[ ] Monitor conntrack usage
[ ] Monitor DNS anomalies
[ ] Separate trusted and untrusted workloads
[ ] Review firewall policies
[ ] Use network segmentation
[ ] Encrypt application traffic
[ ] Monitor connection resets
[ ] Review shared NAT environments
The goal is not to remove NAT.
The goal is to ensure that NAT is only one component of the security architecture.
Why NatJack Matters
The most interesting aspect of NatJack is not simply another security bug.
It highlights a broader problem in infrastructure security.
Modern networks contain many layers:
Application
|
TLS
|
Container
|
Virtual Network
|
Firewall
|
NAT
|
Internet
Each layer makes assumptions about the layer below it.
When those assumptions are wrong, vulnerabilities can cross traditional security boundaries.
This is exactly why infrastructure security needs to be treated as part of application security.
Final Takeaway
NAT remains an important technology.
But developers and infrastructure engineers should stop thinking of it as a security mechanism by itself.
NatJack demonstrates why connection tracking, shared NAT environments and network state deserve security attention.
The practical model should be:
NAT
+
Firewall
+
Segmentation
+
TLS
+
Monitoring
+
Patching
Not:
NAT = Security
Understanding what happens below the application layer is becoming increasingly important as modern applications depend on containers, cloud networking, virtualization and shared infrastructure.
For the complete technical analysis of NatJack, including attack scenarios and defensive recommendations:
NatJack: New Attack Class Can Hijack TCP Sessions and Spoof DNS Through NAT Manipulation
Top comments (0)