Introduction
Pendant trente ans, le NAT a joué un rôle discret mais fondamental dans l'architecture réseau des entreprises. Derrière cet acronyme — Network Address Translation — se cache une hypothèse tacite : les machines partageant la même table NAT peuvent se faire confiance. C'est précisément cette hypothèse que NatJack vient remettre en cause.
Quand la frontière réseau devient une illusion
Révélées à Black Hat USA 2026 par le chercheur Malcolm Stagg, les attaques NatJack exploitent non pas un bug isolé dans une implémentation, mais une faille architecturale inscrite dans la conception même du NAT. La démonstration est sans appel : sur 32 produits et configurations testés auprès de 13 fournisseurs différents, chacun s'est révélé vulnérable à au moins une des techniques de la famille NatJack.
La condition d'attaque est relativement simple : l'attaquant doit partager la même frontière NAT que sa cible. Dans un environnement de bureau partagé, une infrastructure Hyper-V multi-tenant, un cluster de conteneurs ou un cloud privé, ce scénario est loin d'être exceptionnel.
Quatre techniques, un seul angle mort
L'arsenal NatJack se décompose en quatre vecteurs distincts :
- Détournement de sessions TCP actives : en manipulant les entrées de la table NAT, l'attaquant peut forcer une connexion établie vers un état fermé, puis en prendre le contrôle.
- Empoisonnement DNS : les requêtes UDP circulant dans le périmètre NAT partagé peuvent être interceptées et leurs réponses falsifiées, exposant les clients à des redirections silencieuses.
- Découverte de ports mappés : il est possible de déterminer quels ports externes correspondent aux connexions actives d'autres clients, facilitant des attaques ciblées ultérieures.
- Saturation de la table NAT : en injectant massivement des flux fictifs, l'attaquant prive les clients légitimes de la possibilité d'établir de nouvelles connexions — un déni de service furtif et difficile à distinguer d'une surcharge légitime.
Deux CVE ont été assignés pour les implémentations les plus répandues : CVE-2026-56181 pour le NAT Windows utilisé par Hyper-V (CVSS 8.3) et CVE-2026-63913 pour Linux Netfilter conntrack (CVSS 8.2). Des correctifs existent pour ces deux cas spécifiques — Linux dans ses branches stables 5.10.259, 5.15.210 et 6.1.176, Windows via les mises à jour de sécurité de cet été.
Ce que cela change pour les équipes réseau
Le point critique est là : NatJack n'est pas une vulnérabilité qu'un patch suffit à colmater dans son ensemble. Le problème est conceptuel. Le NAT a été conçu pour translater des adresses, pas pour isoler des locataires. Tant que des workloads non maîtrisés partagent la même table NAT que des systèmes sensibles, le risque structurel demeure.
Pour les équipes réseau et sécurité, les conséquences pratiques sont claires :
- La segmentation VLAN et l'isolation des ports de commutateur n'offrent aucune protection contre NatJack, qui opère aux couches 3 et 4 du modèle réseau.
- Généraliser le chiffrement des flux internes — TLS systématique, architecture zéro confiance — reste la défense la plus robuste contre le détournement de sessions et l'empoisonnement DNS.
- IP Source Guard peut limiter l'injection de flux forgés en amont.
- Les architectures Hyper-V ou cloud privé doivent séparer les workloads non fiables sur des passerelles NAT distinctes, plutôt que de compter sur une isolation logique à l'intérieur d'une même table.
L'hypothèse de confiance que l'on ne questionne jamais
Ce que NatJack illustre, au fond, c'est un angle mort systémique : les équipes IT héritent d'hypothèses de sécurité implicites inscrites dans des protocoles conçus il y a des décennies, et les exportent dans des contextes qu'ils n'ont jamais été pensés pour adresser. Le NAT comme frontière de confiance, c'est une convention, pas une garantie.
Pour les DSI et RSSI confrontés à des environnements multi-tenant — virtualisation, conteneurisation ou cloud hybride — NatJack est un rappel concret : l'architecture réseau doit être repensée à partir du postulat que les co-locataires sont potentiellement hostiles, et non plus présumés bienveillants par défaut.