Une vulnérabilité critique du noyau Linux liée au protocole TCP peut permettre l'exécution de code à distance (CVE-2026-98432)

TL;DR

CVE-2026-98432 est une faille liée à la manière dont le noyau Linux établit les connexions TCP IPv4, présente dans le noyau 4.4 et les versions ultérieures. L'équipe CVE du noyau lui attribue une note de 9,8 sur 10. Anthropic indique qu'un modèle de recherche Claude non encore publié a généré un exploit permettant à un attaquant distant d'obtenir les droits root sur un serveur Linux équipé d'un écouteur MPTCP (Multipath TCP), sans identifiants et sans interaction de l'utilisateur. AWS confirme que, dans des conditions spécifiques, un attaquant distant non authentifié pourrait parvenir à exécuter du code à distance. Au 2 novembre, aucun fournisseur ni CERT n’ avait signalé d’attaques en milieu réel et le CVE ne figurait pas dans le catalogue des vulnérabilités connues pour avoir été exploitées de la CISA. Le chercheur Marcus Hutchins a depuis signalé ce qui semble être des acteurs malveillants scannant Internet à la recherche de serveurs prenant en charge le MPTCP.

Comment corriger la vulnérabilité CVE-2026-98432

Installez un noyau corrigé et redémarrez. AWS considère qu’il s’agit de la seule solution complète et précise qu’un « livepatch » permet également de résoudre le problème.

Commencez par identifier toutes les machines virtuelles concernées. N’oubliez pas d’inclure les hôtes oubliés et les nœuds de vos conteneurs. La fonctionnalité « Machines virtuelles » deAikidosignale celles qui exécutent un noyau concerné.

Amazon Linux. Des paquets de noyau corrigés sont disponibles pour Amazon Linux 2 et 2023, pour les versions 4.14, 5.4, 5.10, 5.15, 6.1, 6.12 et 6.18 du noyau.

• Amazon Linux 2 : sudo yum update kernel && sudo reboot
• Amazon Linux 2023 : sudo dnf update kernel --releasever=latest && sudo reboot

Kubernetes, ECS et autres services AWS gérés

• EKS : mettez à jour les groupes de nœuds gérés, les nœuds autogérés et les nœuds Karpenter vers la version AMI v20261031 ou une version ultérieure. Le mode automatique d'EKS remplace automatiquement les nœuds.
• ECS sur EC2 : mettez à jour le noyau et redémarrez, ou remplacez les instances par celles issues de l'AMI optimisée pour ECS, version 20261031.
• Fargate : les tâches créées après le 1er novembre 2026 à 6 h 00 (PDT) utilisent la plateforme mise à jour. Les tâches existantes seront supprimées conformément à vos paramètres de suppression des tâches, mais vous pouvez les remplacer plus tôt si vous le souhaitez.
• Bottlerocket : les AMI mises à jour étaient attendues à partir du 2 novembre.

Autres distributions. Consultez le suivi de votre fournisseur, car la situation évolue quotidiennement.

• Ubuntu: la version 26.10 est corrigée dans la version 7.3.0-10.10. Les correctifs pour les versions 22.04 (5.15.0-203.213), 24.04 (6.8.0-149.149) et 26.04 (7.0.0-43.43) se trouvent dans le répertoire de test « -proposed », à partir duquel apt n'effectue pas d'installation par défaut ; vous devez donc l'activer et installer le noyau explicitement à l'aide des commandes indiquées dans l'article de Canonical. Les versions 16.04, 18.04 et 20.04 affichent toujours un correctif en attente, et les noyaux « cloud », «FIPS» et «temps réel» disposent de leurs propres versions sur la page CVE d'Ubuntu.
• Red Hat: des noyaux corrigés ont été mis à disposition le 1er novembre pour RHEL 8 (RHSA-2026:93414), RHEL 9 (RHSA-2026:93412) et RHEL 10 (RHSA-2026:93413), avec des avis supplémentaires pour les flux EUS, SAP et NVIDIA. Au 3 novembre, le noyau kernel-rt de RHEL 9 ainsi que les images CoreOS d'OpenShift 4 et 5 figuraient toujours parmi les éléments affectés, tandis que RHEL 6 et 7 ne sont pas concernés.
• Debian, Oracle Linux et SUSE : des paquets corrigés ont été mis à disposition pour au moins certains noyaux, selon The Hacker News.

Compiler son propre noyau. Le correctif en amont est disponible dans les versions Linux 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 et 7.3. L'équipe CVE du noyau recommande de passer à la dernière version stable du noyau plutôt que de sélectionner ponctuellement le correctif.

Comment « Aikido » peut vous aider

AikidoL'analyse des machines virtuelles détecte la vulnérabilité CVE-2026-98432 sur vos machines virtuelles connectées, avec un niveau de gravité de base de 9,8. Aikido ajuste le niveau de gravité pour chaque machine virtuelle en fonction de son accessibilité réseau ; utilisez donc la vue « Accessibilité » pour identifier les machines virtuelles accessibles depuis Internet et appliquez les correctifs à celles-ci en priorité.

Si vous n’avez pas encore connecté vos machines virtuelles, rendez-vous dans la section « Machines virtuelles » sur Aikido et sélectionnez « Connecter des machines virtuelles ». Aikido prend en charge AWS, Azure et GCP.

La détection s'appuie sur les avis des éditeurs. Lorsqu'un éditeur n'a pas encore publié de correctif pour le noyau, un hôte peut être vulnérable sans pour autant apparaître comme affecté ; veillez donc à consulter également le suivi de votre distribution. Un hôte sur lequel la mise à jour a été installée mais qui n'a pas encore été redémarré peut apparaître comme corrigé ; redémarrez-le donc au préalable.

‍

Si vous ne pouvez pas encore installer le correctif

Ces mesures permettent de réduire l'exposition à la vulnérabilité. Aucune d'entre elles ne corrige le bug ; il convient donc d'appliquer le correctif et de redémarrer dès que votre fournisseur met à disposition un nouveau noyau. AWS présente les deux premières comme des mesures provisoires, tandis que Red Hat indique qu'aucune des mesures d'atténuation qu'elle a examinées n'est facile à déployer, adaptée à la plupart des installations et stable. Si vous exécutez un serveur Go qui n'est pas derrière un équilibreur de charge, utilisez le paramètre Go ci-dessous.

1. Désactivez MPTCP. Définissez `net.mptcp.enabled=0`. Pour les programmes écrits en Go 1.24 ou version ultérieure, définissez `GODEBUG=multipathtcp=0`. Cela est important car l’exploit d’Anthropic nécessitait un écouteur MPTCP, et les versions 1.24 et ultérieures de Go en demandent par défaut lorsque le noyau autorise MPTCP. Il s'agit d'une mesure de sécurité peu efficace : l'équipe de sécurité de Go qualifie la désactivation au cas par cas de « fragile », car un seul écouteur MPTCP exposé suffit à rendre le système vulnérable. Selon Marcus Hutchins, définir net.mptcp.enabled=0 laisse en place les sockets MPTCP déjà ouverts ; il faut donc redémarrer les services concernés par la suite. Pour lister les écouteurs MPTCP, exécutez la commande sudo ss -Mlnp.
2. Rejeter les paquets IPv4 contenant des options IP. AWS fournit la règle suivante : iptables -I INPUT 1 -m u32 --u32 '0>>24&0x0f=6:15' -j DROP. Cela est important car la faille réside dans la manière dont le noyau gère les options IP stockées avec une connexion en attente, et l'attaque utilise un paquet SYN qui les transporte. Sur AWS Network Firewall, AWS publie une règle « stateful » équivalente qui nécessite un ordre de règles strict.
3. Placez l'hôte derrière un équilibreur de charge distinct ou un service géré qui met fin à la connexion TCP avant que le trafic n'atteigne votre noyau. Un proxy situé sur le même hôte ne fait pas l'affaire. Mettez tout de même à jour les instances situées derrière lui.

Comment vérifier si le correctif est bien en ligne

Une mise à jour du noyau ne prend effet qu'après un redémarrage ; vérifiez donc le noyau en cours d'exécution, et non celui qui est installé.

uname -r

Comparez le résultat avec la version corrigée du noyau indiquée dans l'avis de sécurité de votre fournisseur. Les fournisseurs réintègrent les correctifs dans leurs versions antérieures ; utilisez donc leur propre version corrigée plutôt que celle de l'amont. Si l'ancienne version apparaît toujours, cela signifie que l'hôte n'a pas redémarré avec le noyau corrigé.

Répétez cette opération sur chaque machine virtuelle, y compris celles que vous avez oubliées et les nœuds situés sous vos conteneurs.

Qui est concerné ?

Tout hôte Linux exécutant le noyau 4.4 ou une version ultérieure et disposant d'un port TCP IPv4 accessible à un attaquant. IPv6 n'est pas concerné par la vulnérabilité principale. Sur AWS, cela concerne les instances EC2 et Lightsail autogérées, les instances de conteneurs ECS sur EC2 et les nœuds EKS. AWS Lambda n'est pas concerné, car les fonctions n'exposent aucun port TCP IPv4 public.

Ce qui se trouve devant l'animateur modifie votre exposition :

• AWS WAF, Application Load Balancer, Classic Load Balancer, les écouteurs TLS de Network Load Balancer, CloudFront et API Gateway. AWS précise que, lorsque vous respectez les bonnes pratiques, ces services ne transmettent pas directement à vos instances les connexions TCP provenant de sources non fiables, et que l'entreprise procède actuellement à la mise à jour de l'infrastructure sous-jacente. Elle recommande toutefois de mettre à jour les instances situées derrière ces services dans un délai de 30 jours.
• Écouteurs TCP du Network Load Balancer et Global Accelerator. AWS recommande à ses clients de mettre à jour la version de leur plateforme dès que des versions corrigées sont disponibles.
• Un proxy tel que nginx ou HAProxy sur votre propre serveur Linux. Il ne s'agit pas d'un pare-feu. C'est le noyau de la machine qui accepte la connexion qui gère la poignée de main TCP ; l'hôte proxy doit donc également disposer du correctif.

Pour les conteneurs, le noyau qui importe est celui du nœud sur lequel ils s'exécutent.

C'est grave à quel point ?

Considérez cela comme urgent pour tout serveur connecté à Internet. Trois points méritent particulièrement d'être soulignés :

• Un exploit permettant d'obtenir les privilèges root à distance a été démontré. L'équipe Frontier Red Team d'Anthropic indique qu'après une première demande, Claude a écrit un exploit permettant d'exécuter des commandes en tant que root sur un serveur Linux équipé d'un écouteur MPTCP (Multipath TCP). Lors de son test, il a fallu 48 minutes pour obtenir une fuite d'adresse du noyau, puis 5 minutes supplémentaires pour parvenir à l'exécution de commandes.
• L'attaquant peut réessayer. Selon Anthropic, une course perdue n'entraîne l'échec que de cette seule phase d'établissement de connexion et ne provoque pas de plantage du système ; un attaquant déterminé peut donc continuer à essayer jusqu'à ce qu'il y parvienne.
• Cette condition préalable est peut-être plus courante qu'il n'y paraît. Une application doit demander l'utilisation du protocole MPTCP lorsqu'elle ouvre une connexion de type « socket », et depuis la version 1.24 de Go, les programmes Go le font par défaut pour les sockets sur lesquelles ils sont à l'écoute, selon l'équipe de sécurité de Go. Le noyau doit également autoriser le protocole MPTCP, et certaines distributions, telles qu'AlmaLinux et CloudLinux, le livrent désactivé par défaut. Lorsqu'il est activé, un serveur Go peut se retrouver à l'écoute sans que personne ne l'ait choisi.

Certaines questions restent en suspens. Anthropic n'a pas divulgué l'exploit, la version du noyau ni la configuration sur laquelle il a effectué ses tests, et l'équipe chargée du noyau chez CloudLinux affirme ne pas avoir pu reproduire le problème signalé. La faille se trouve dans le code TCP IPv4 standard, et ni la fiche CVE ni le correctif du noyau ne mentionnent le protocole MPTCP ; l'équipe de sécurité de Go estime donc que les systèmes ne disposant pas d'écouteurs MPTCP pourraient être exposés à des attaques similaires. Le bulletin de Red Hat précise que le MPTCP n’est pas une condition nécessaire à l’exploitation de cette faille, et que les nœuds OpenShift dans leur configuration par défaut, avec le MPTCP désactivé, restent vulnérables. Au 2 novembre, aucun éditeur ni aucun CERT n’ avait signalé d’attaques en milieu réel. Marcus Hutchins rapporte que des proxys résidentiels et des serveurs VPN basés en Russie ont commencé à sonder le port 443 via MPTCP le 2 novembre, ce qu’il soupçonne être une recherche de cette vulnérabilité CVE ; son propre scan, effectué le 30 octobre, a quant à lui identifié environ 2,1 millions de serveurs accessibles via MPTCP sur ce port.

La plupart des fournisseurs lui attribuent une note inférieure à celle de l'équipe du noyau, car ils estiment que la course est plus difficile à remporter :

‍Qu'est-ce que la vulnérabilité CVE-2026-98432 ?

En termes simples, le noyau peut libérer un bloc de mémoire alors qu'un autre processeur est encore en train de le lire. Selon l'équipe CVE du noyau, un attaquant capable de contrôler la synchronisation peut exploiter cette faille pour lire ou corrompre la mémoire du noyau, voire provoquer un plantage du système.

Au cours d'une poignée de main TCP, le client envoie un paquet SYN et le serveur répond par un SYNACK. Le noyau conserve les options IP du paquet SYN avec un marqueur de place pour la connexion semi-ouverte, appelé « request socket ». Dans la fonction tcp_v4_syn_recv_sock(), le nouveau processus enfant socket prend en charge ces options sans les copier. Si un autre processeur est encore en train de construire un paquet SYNACK pour un paquet SYN retransmis, les options peuvent être libérées alors qu’elles sont encore utilisées. Il s’agit là d’une utilisation après libération (use-after-free), ici dans la fonction ip_options_build().

La demande de migration « socket » (net.ipv4.tcp_migrate_req=1, ou un programme BPF « reuseport migrate ») ouvre une voie similaire. Le correctif en amont remplace les appels à `free` par `kfree_rcu()`, qui attend qu’aucun processeur ne soit plus en train de lire la mémoire. IPv6 évite le premier problème car le noyau copie les options pour les connexions IPv6. Un problème de migration similaire existe pour IPv6, mais il ne s'applique que lorsque CALIPSO définit des options IPv6, et le noyau y remédie dans un correctif distinct.

Ce bogue est apparu dans la version 4.4 de Linux. Les développeurs du noyau ont appliqué le correctif le 5 octobre, et le CVE a été publié le 15 octobre. Le correctif du noyau mentionne qu'un chercheur d'Anthropic a signalé ce bogue.

‍