NatJack: Neue Angriffsklasse manipuliert NAT-Tabellen in Windows und Linux
Die Angriffsklasse NatJack erlaubt TCP-Session-Hijacking und DNS-Spoofing durch Manipulation von NAT-Verbindungstabellen. Windows Hyper-V und Linux Netfilter sind mit eigenen CVEs betroffen.
Der Sicherheitsforscher Malcolm Stagg hat auf der Black Hat USA 2026 eine neue Angriffsklasse namens NatJack vorgestellt, die eine grundlegende Annahme vieler NAT-Implementierungen (Network Address Translation) aushebelt: dass Systeme hinter demselben NAT einander nicht gegenseitig manipulieren können. Zwei implementierungsspezifische Lücken wurden bereits mit CVE-Nummern versehen, eine in Windows (Hyper-V) und eine in Linux (Netfilter conntrack).
Was ist passiert?
NatJack manipuliert den Verbindungsstatus von NAT-Implementierungen, um aktive TCP-Sitzungen zu kapern, DNS-Antworten zu fälschen, extern gemappte Ports offenzulegen und NAT-Tabellen zu erschöpfen. Die Forschung wurde unabhängig durch mehrere Implementierungen bestätigt, darunter Windows und Linux. Zwei konkrete CVEs sind bekannt: CVE-2026-56181 (CVSS 8.3) im Windows-NAT, das von Hyper-V genutzt wird, sowie CVE-2026-63913 (CVSS 8.2) im Linux-Netfilter-Conntrack.
Für Linux beschreibt der kernel.org-CNA-Eintrag, dass ein präparierter SYN-Paket-Ablauf gefolgt von einem Reset-Paket mit ungültiger Sequenznummer einen aktiven Netfilter-NAT-Eintrag vorzeitig in den Zustand "geschlossen" zwingen kann, weil die Conntrack-Logik die Richtung nicht korrekt validierte. Gefixte Stable-Releases sind 5.10.259, 5.15.210, 6.1.176, 6.6.143, 6.12.93, 6.18.35, 7.0.12 und 7.1.
Wer ist betroffen?
Betroffen sind Windows-Systeme mit Hyper-V (CVE-2026-56181) sowie Linux-Systeme mit den genannten Kernel-Versionen vor den Fixes (CVE-2026-63913). Voraussetzung für einen erfolgreichen Angriff ist, dass der Angreifer privilegierten Zugriff auf ein System besitzt, das sich hinter demselben NAT wie das Zielsystem befindet, etwa in geteilten Cloud-Umgebungen, Multi-Tenant-Netzwerken oder Umgebungen mit gemeinsamer Internetanbindung mehrerer Kunden.
Nicht betroffen im engeren Sinn sind Systeme, bei denen keine potenziell unvertrauenswuerdigen Workloads dasselbe NAT-Segment teilen wie vertrauenswürdige Systeme. Ein externer Angreifer ohne Zugriff auf ein System im selben NAT-Segment kann NatJack nicht direkt ausnutzen.
Wie kritisch ist das?
Beide CVEs liegen mit CVSS 8.2 und 8.3 im hohen Bereich. Es gibt keinen einzelnen Patch, der die gesamte Angriffsklasse schließt, da NatJack ein strukturelles Designproblem in NAT-Implementierungen betrifft, nicht nur einen einzelnen Softwarefehler. The Hacker News fand zum Stand 7. August 2026 keine öffentlichen Belege für aktive Ausnutzung in freier Wildbahn. Es handelt sich also um eine bekannte, aber nach aktuellem Kenntnisstand noch nicht aktiv ausgenutzte Schwachstellenklasse mit Proof-of-Concept-Nachweis der Forscher.
Was sollten Admins jetzt tun?
- Verfügbare Windows-Updates für Systeme mit aktivem Hyper-V prüfen und CVE-2026-56181 gegen den eigenen Patchstand abgleichen
- Linux-Kernel-Version gegen die gefixten Stable-Releases prüfen (5.10.259, 5.15.210, 6.1.176, 6.6.143, 6.12.93, 6.18.35, 7.0.12, 7.1 oder neuer)
- Untrusted Workloads von vertrauenswürdigen Systemen trennen, wenn sie dieselbe NAT-Infrastruktur teilen, etwa durch separate Subnetze oder eigene NAT-Gateways
- Verschlüsselung auch für internen Netzwerkverkehr in Betracht ziehen, nicht nur für externe Verbindungen
- Wo verfügbar, IP Source Guard aktivieren, um gefälschte Quelladressen im lokalen Segment zu erschweren
- Multi-Tenant- und geteilte Cloud-Umgebungen besonders prüfen, da dort das Angriffsszenario "privilegierter Zugriff im selben NAT-Segment" am wahrscheinlichsten vorliegt
Einordnung für Unternehmen
Für kleine und mittlere Unternehmen mit klassischer Netzwerkstruktur ohne geteilte NAT-Segmente mit Fremdsystemen ist die unmittelbare Dringlichkeit begrenzt. Relevant wird NatJack vor allem in Umgebungen mit gemeinsam genutzter Infrastruktur, etwa bei Hosting-Kunden hinter demselben Gateway, in Virtualisierungsclustern mit mehreren Mandanten oder in Cloud-Umgebungen mit geteiltem NAT. Wer Windows-Server mit Hyper-V oder Linux-Systeme mit gemeinsamer Netzwerkanbindung mehrerer Kunden betreibt, sollte die Kernel- und Hyper-V-Updates zeitnah einplanen.
Passende Anleitungen auf S-EDV
- DirtyClone CVE-2026-43503: Linux-Kernel-Root-Eskalation – Vergleichbarer Fall einer Linux-Kernel-Sicherheitslücke mit Patchempfehlung.
- CISA KEV: Warum der Known Exploited Vulnerabilities Catalog für Admins Pflicht ist – Einordnungshilfe für die Priorisierung von Patches.
