New security research from Synack is challenging a decades-old assumption behind network address translation, revealing an attack class capable of affecting independently developed NAT implementations across Windows, Linux and macOS.
Synack Red Team researcher Malcolm Stagg presented the research at Black Hat USA 2026, describing the attack class as “NatJack.”
Unlike many security vulnerabilities caused by an isolated programming mistake, NatJack targets a fundamental design assumption: devices sharing a NAT table can trust one another.
That assumption becomes considerably more dangerous when untrusted workloads share infrastructure with sensitive systems.
Four Ways To Attack NAT
Stagg’s research identified four techniques that attackers can potentially use against affected NAT implementations.
The techniques include hijacking active TCP connections, poisoning DNS responses, identifying ports assigned to other connections and exhausting a device’s NAT table to cause denial of service.
Testing found affected behavior across independently developed implementations including Windows, Linux and macOS.
Two vulnerabilities have received CVE assignments so far.
CVE-2026-56181 affects Microsoft Windows NAT in Hyper-V, while CVE-2026-63913 affects the Linux netfilter conntrack subsystem. Additional vendor advisories or vulnerability assignments could emerge as coordinated disclosure continues.
The Problem Is Bigger Than A Software Bug
NatJack is notable because the underlying issue is not simply one developer making a coding mistake.
According to the research, the problem stems from assumptions embedded in the way NAT systems behave.
For much of the internet’s history, treating systems behind the same NAT environment as relatively trustworthy may have been reasonable.
Modern infrastructure looks very different.
Cloud environments, virtualization, containers, shared hosting and other multi-tenant architectures can place workloads with very different trust levels behind shared network infrastructure.
That can turn a previously acceptable design assumption into an attack surface.
No Single Patch Solves NatJack
The nature of the issue also makes remediation more complicated.
Synack says there is no single patch capable of eliminating NatJack across affected implementations.
Fixes including Linux kernel 6.6.142 and later and FreeBSD 15.0 and later can make exploitation more difficult, but they do not eliminate the broader design issue.
Synack expects remediation to happen gradually as vendors address individual implementations.
In the meantime, the company recommends encrypting traffic, including internal communications, separating untrusted workloads from trusted systems and using network protections such as IP Source Guard where appropriate.
Automated Scanners May Miss The Problem
NatJack also exposes a limitation of conventional vulnerability management.
Automated scanners are generally good at identifying known vulnerable software versions, exposed services and recognizable configuration problems.
Design-level weaknesses can be considerably harder to identify.
Because NatJack is based on network behavior rather than a single recognizable software signature, Synack says it may not appear through conventional automated vulnerability scanning.
For security teams, that strengthens the case for testing how infrastructure actually behaves under adversarial conditions rather than relying entirely on vulnerability databases and automated scans.
The Bottom Line
NatJack matters because it challenges an assumption buried deep inside modern network infrastructure.
Windows, Linux and macOS implementations were developed independently, yet Synack’s testing found the underlying behavior across multiple platforms. That suggests the issue is architectural rather than isolated to one vendor.
Organizations do not need to abandon NAT, but they may need to reconsider how much trust they place between systems sharing the same network translation infrastructure.
As enterprise environments become more distributed, virtualized and multi-tenant, old assumptions about what sits “inside” a trusted network are becoming increasingly difficult to defend.