Une recherche présentée lors de Black Hat USA 2026 a révélé NatJack, une nouvelle catégorie d’attaques contre la traduction d’adresses réseau (NAT) qui ne repose pas sur une vulnérabilité logicielle spécifique, mais sur la façon dont différentes implémentations gèrent les connexions et la confiance entre systèmes partageant une table NAT. Les tests effectués par le chercheur Malcolm Stagg ont mis en évidence des comportements affectés sous Windows, Linux et macOS, tandis que deux vulnérabilités associées ont déjà reçu des identifiants CVE.

Les principales caractéristiques de NatJack en 30 secondes

• NatJack combine quatre techniques pour manipuler le fonctionnement des implémentations NAT.
• Il peut permettre de détourner des connexions TCP, de modifier des réponses DNS, de découvrir des ports attribués et de saturer les tables NAT.
• Les tests ont révélé des comportements affectés sur des codes indépendants pour Windows, Linux et macOS.
• Deux CVE ont été attribués : CVE-2026-56181 et CVE-2026-63913, avec des scores CVSS allant de 7,2 à 9,6.
• Il n’existe pas de correctif universel : les environnements cloud, Kubernetes et multi-locataires nécessitent une attention particulière.

NatJack a été développé sur plusieurs années par Malcolm Stagg, chercheur chez SODIUM-24 et membre du Red Team de Synack. Son travail a été présenté à Black Hat USA 2026 sous le titre Breaking Trust Boundaries: Exploiting Design Assumptions in Network Infrastructure.

Pour les administrateurs et responsables d’infrastructure, l’aspect le plus important est que NatJack ne doit pas être considéré simplement comme une vulnérabilité supplémentaire d’un routeur.

Aujourd’hui, la NAT apparaît dans les hyperviseurs, serveurs de conteneurs, Kubernetes, passerelles cloud, pare-feux, ponts virtuels et autres composants réseaux. Une seule table peut gérer des connexions provenant de machines virtuelles ou de charges de travail avec des niveaux de confiance radicalement différents.

C’est là qu’une conception héritée des premières décennies d’Internet prend de nouvelles implications.

Le problème n’est pas la NAT elle-même, mais la gestion partagée de sa table

La NAT a été créée principalement pour permettre à plusieurs appareils disposant d’adresses privées de communiquer avec Internet en utilisant beaucoup moins d’adresses IPv4 publiques.

Pour assurer cette communication, l’appareil réalisant la NAT doit connaître la correspondance entre chaque connexion et le système correspondant.

En termes simplifiés, lorsqu’une machine avec une adresse privée initie une connexion vers Internet, la NAT peut modifier l’adresse et le port source. Elle conserve ensuite cette information pour que les réponses puissent revenir vers le bon appareil.

Un exemple simplifié :

Serveur A
10.0.0.10:49152
        │
        ▼
┌─────────────────────────┐
│      Passerelle NAT     │
│                         │
│ 10.0.0.10:49152         │
│       ↕                 │
│ 203.0.113.10:62001      │
└─────────────────────────┘
        │
        ▼
      Internet

L’implémentation doit conserver des états, des attributions de ports et suivre les connexions pour que ce mécanisme fonctionne correctement.

Sous Linux, un composant clé est netfilter conntrack, qui conserve des informations sur les flux actifs. Windows dispose également de mécanismes NAT utilisés, notamment, dans Hyper-V et les technologies de virtualisation.

L’étude sur NatJack part d’une question simple : que se passe-t-il si un des systèmes partageant cette infrastructure NAT tente intentionnellement de manipuler son comportement ?

Selon Synack, historiquement, de nombreuses implémentations ont supposé un certain niveau de confiance entre les dispositifs derrière la même table NAT.

Dans un centre de données moderne, cette hypothèse peut ne plus être valable.

Quatre techniques d’attaque distinctes

Stagg a documenté quatre techniques au sein de NatJack, chacune ciblant une partie différente du fonctionnement de la NAT.

La première permet d’essayer de détourner des connexions TCP actives.

L’attaquant cherche à manipuler l’état conservé par la NAT pour une connexion existante afin d’interférer avec le trafic d’un autre système. Les conséquences dépendent également du protocole supérieur utilisé : contrôler un flux TCP ne signifie pas automatiquement rompre le chiffrement TLS protégeant la session.

La deuxième technique concerne DNS sur UDP.

NatJack peut exploiter certaines caractéristiques du suivi des connexions pour tenter d’introduire des réponses DNS falsifiées. Si l’attaque réussit et qu’aucune autre protection n’est en place, un système pourrait accepter une réponse frauduleuse et résoudre un nom de domaine vers une adresse contrôlée par l’attaquant.

La troisième technique permet d’identifier le port externe attribué par la NAT à une connexion appartenant à une autre charge.

Cette information peut réduire l’espace de recherche nécessaire dans d’autres attaques.

La quatrième technique vise à épuiser les ressources disponibles.

Les dispositifs NAT gèrent un nombre limité d’entrées pour suivre les connexions. Un attaquant capable de générer suffisamment d’états peut tenter de remplir la table NAT ou le conntrack, compliquant ou bloquant la création de nouvelles connexions, provoquant une déni de service.

Toutes ces techniques ne sont pas nécessairement efficaces sur toutes les plateformes ni sans conséquences. Leur exploitation dépend de l’implémentation, de la configuration, de la topology et des capacités de l’attaquant.

Hyper-V et netfilter ont déjà des CVE

La divulgation coordonnée a permis d’attribuer deux identifiants publics jusqu’à présent.

CVE-2026-56181 concerne la NAT de Microsoft Windows utilisée dans Hyper-V.

La seconde, CVE-2026-63913, est liée au sous-système conntrack de netfilter sous Linux.

Synack indique que les scores CVSS associés à ces vulnérabilités varient entre 7,2 et 9,6, allant de haute à critique.

Le fait que deux CVE concernent des plateformes distinctes est révélateur, car cela montre la nature du problème sans que cela implique un code malveillant commun. Leurs implémentations ont été développées de manière indépendante.

L’étude a également identifié des comportements vulnérables sous macOS.

Synack considère ainsi que NatJack représente une catégorie d’attaques contre certaines hypothèses de conception de la NAT, plutôt qu’une vulnérabilité limitée à une fonction précise.

La divulgation continue et de nouveaux rapports ou CVE pourraient apparaître.

Pourquoi Kubernetes et les environnements cloud nécessitent une attention particulière

Le contexte probablement le plus critique pour NatJack n’est pas le réseau domestique, mais les infrastructures multi-locataires.

Un serveur moderne peut héberger des dizaines ou des centaines de machines virtuelles ou de conteneurs.

┌──────────────┐
│ VM client A │──┐
└──────────────┘  │
                  │
┌──────────────┐  │      ┌─────────────┐
│ VM client B │──┼─────▶│ NAT partagé │────▶ Internet
└──────────────┘  │      └─────────────┘
                  │
┌──────────────┐  │
│ Conteneur X │──┘
└──────────────┘

Si tous ces systèmes appartiennent au même administrateur et ont un niveau de confiance similaire, le risque est différent.

Mais dans un cloud public, une plateforme Kubernetes partagée ou un service permettant d’exécuter du code tiers, il est possible que des charges fiables et non fiables utilisent des composants NAT communs.

Synack recommande d’inspecter particulièrement les routeurs, pare-feux, Docker, Kubernetes, Hyper-V, passerelles NAT cloud, ponts et commutateurs virtuels, ainsi que les services publics de conteneurs et de virtualisation.

Cela ne signifie pas que tous les déploiements Kubernetes sont vulnérables à une attaque concrète, mais la question essentielle pour un administrateur est :

Une charge sous contrôle d’un utilisateur non fiable peut-elle partager la même infrastructure NAT que des systèmes sensibles ?

Si la réponse est oui, NatJack mérite une attention approfondie.

Une table conntrack peut aussi devenir une ressource ciblable

Pour les administrateurs Linux, le composant particulièrement critique est conntrack.

Le noyau utilise ce sous-système pour suivre les connexions et dispose de paramètres permettant de consulter et limiter le nombre d’entrées.

Parmi eux :

nf_conntrack_count
nf_conntrack_max
nf_conntrack_buckets

nf_conntrack_count indique le nombre d’entrées actuellement en mémoire, tandis que nf_conntrack_max définit la limite maximale.

Une infrastructure où le nombre de connexions atteint subitement la limite peut rencontrer des difficultés pour établir de nouveaux flux.

NatJack exploite ce comportement en épuisant délibérément la table.

Pour les équipes d’exploitation, cela signifie que les métriques de conntrack ne doivent pas seulement être des indicateurs de performance, mais aussi constituer une alerte de sécurité.

Des pics anormaux de connexions, une utilisation inhabituelle de la table NAT ou certains modèles de paquets peuvent justifier une enquête approfondie.

Aucun correctif universel pour NatJack, mais des mesures adaptées

C’est probablement la différence principale entre NatJack et une vulnérabilité classique.

Il n’existe pas de mise à jour unique à déployer pour régler le problème sur toutes les architectures.

Synack note que certaines versions ont déjà intégré des mesures pour compliquer certaines techniques. Parmi elles, le kernel Linux 6.6.142 et ultérieurs, ainsi que FreeBSD 15.0 et suivants.

Mais ces ajustements ne solutionnent pas la problématique fondamentale de conception.

Chaque fournisseur devra examiner sa propre implémentation et décider des modifications à apporter, notamment sur l’attribution des ports, le suivi des connexions, la validation des paquets, etc.

Le processus pourrait s’étendre tant que la divulgation coordonnée continue.

C’est pourquoi la mitigation architecturale est aussi importante que la mise à jour logicielle.

Ce que peuvent faire les administrateurs

La première recommandation est de maintenir à jour les kernels, hyperviseurs, systèmes d’exploitation, pare-feux et passerelles. Mais NatJack invite aussi à repenser l’architecture réseau.

Synack recommande d’éviter autant que possible le partage d’infrastructure NAT entre charges de confiance différente.

Cela peut se faire par la segmentation en séparant réseaux, passerelles ou domaines de sécurité, afin d’empêcher qu’un conteneur ou une VM non fiable n’accède au même contexte NAT que des systèmes sensibles.

Le chiffrement du trafic interne doit également être privilégié.

TLS est souvent considéré comme allant de soi pour Internet, mais certains réseaux privés maintiennent des services internes sans chiffrement, estimant que leur présence physique limite les risques.

NatJack illustre à nouveau que cette confiance implicite est problématique.

Pour DNS, Synack recommande d’envisager DNSSEC et DNS chiffré, ainsi que des mécanismes comme IP Source Guard pour réduire certains scénarios de spoofing.

Limiting les capacités réseau et les privilèges des conteneurs et charges non indispensables est également conseillé.

Enfin, les responsables d’infrastructure devraient surveiller l’utilisation des tables NAT, du conntrack, des modèles de paquets inhabituels et des changements imprévus dans le nombre de connexions.

La conclusion technique de NatJack n’est pas que la NAT est défectueuse ou doit disparaître, mais que la NAT ne doit pas automatiquement être considérée comme une frontière de sécurité entre charges de confiance différente.

Ce point est crucial en 2026, où une technologie conçue pour partager des adresses IPv4 est aujourd’hui intégrée dans des hyperviseurs, environnements conteneurisés et clouds, où des systèmes d’utilisateurs différents peuvent coexister sur la même infrastructure.

NatJack démontre que certaines décisions prises avant l’émergence de ces scénarios doivent être réévaluées.

Questions fréquentes

Qu’est-ce que NatJack ?

NatJack est une catégorie d’attaques découverte par Malcolm Stagg, exploitant certains comportements et hypothèses de confiance présents dans les implémentations NAT. Elle inclut des techniques contre TCP, DNS, l’attribution de ports et la gestion des tables NAT.

Quels systèmes sont affectés par NatJack ?

Les tests ont révélé des comportements vulnérables sur des implémentations indépendantes pour Windows, Linux et macOS. Le risque spécifique dépend de chaque implémentation, configuration et architecture.

Quels CVE sont liés à NatJack ?

Deux CVE ont été attribués à ce jour : CVE-2026-56181, concernant la NAT sous Windows dans Hyper-V, et CVE-2026-63913, relative à connexin-tracking dans Linux (netfilter). La divulgation continue.

Comment atténuer NatJack ?

En plus de mettre à jour les correctifs dès qu’ils sont disponibles, Synack recommande de chiffrer les communications internes et externes, de séparer charges de confiance et non-confiance, d’éviter le partage NAT entre niveaux, de sécuriser DNS, de limiter les privilèges et d’observer l’usage des tables NAT et du conntrack.

Sources :