CVE-2026-98432 : Faille critique du protocole TCP du noyau Linux permettant l’exécution de code à distance

Une vulnérabilité critique dans la pile de mise en réseau IPv4 TCP du noyau Linux pourrait permettre à un attaquant distant non authentifié de provoquer une corruption de mémoire, de faire planter des systèmes vulnérables et potentiellement d’exécuter du code arbitraire avec des privilèges root. Identifiée sous le code CVE-2026-98432, la faille présente un score CVSS 3.1 de 9.8 et existe dans le noyau Linux depuis la version 4.4.

La vulnérabilité provient d’une condition de concurrence qui peut amener le noyau à accéder aux données d’option IP après que la mémoire sous-jacente ait déjà été libérée. Un attaquant capable d’atteindre un service TCP IPv4 exposé peut tenter de déclencher la condition en utilisant des requêtes de connexion spécialement minutées contenant des options IPv4. Aucune authentification, privilèges locaux ou interaction utilisateur ne sont requis.

L’intérêt pour la sécurité a considérablement augmenté après qu’Anthropic a révélé qu’un modèle de recherche interne de Claude avait développé un exploit fonctionnel capable d’exécuter une commande root à distance sur un serveur Linux avec un écouteur Multipath TCP (MPTCP). L’exploit divulgue d’abord un pointeur de noyau pour contourner KASLR puis utilise la même condition d’utilisation après libération pour corrompre la mémoire et rediriger le flux de contrôle du noyau. Anthropic n’a pas publié le code de l’exploit.

Il est important de noter que la vulnérabilité sous-jacente ne se limite pas au MPTCP. Red Hat confirme que les systèmes avec une mise en réseau TCP IPv4 ordinaire restent vulnérables même lorsque le MPTCP est désactivé, y compris les configurations par défaut de Red Hat Enterprise Linux.

Contacter les Ventes

Au 4 novembre 2026, aucun fournisseur Linux, CERT ou autre source examinée n’a signalé d’exploitation confirmée de la faille dans des attaques réelles. Du code de recherche public démontrant des parties de la vulnérabilité existe, mais un exploit publié publiquement fournissant la pleine capacité de root à distance démontrée par Anthropic n’a pas été documenté.

Les équipes de sécurité peuvent utiliser la plateforme d’Intelligence de Détection Native IA de SOC Prime pour renforcer leurs défenses contre l’exploitation de vulnérabilités émergentes, opérationnaliser le renseignement sur les menaces et accélérer la chasse aux menaces dans les environnements SIEM, EDR, XDR, et Data Lake.

Détecter CVE-2026-98432 en surveillant le trafic inhabituel IPv4 TCP contenant des options IP, des tentatives de connexion répétées conçues pour déclencher des conditions de concurrence, des plantages de noyau ou des événements de corruption de mémoire, et des activités suspectes qui pourraient indiquer une exploitation réussie.

Le contenu de détection peut ne pas être disponible pour chaque CVE. Vérifiez la plateforme SOC Prime pour une couverture actuelle. Si les détections pertinentes ne sont pas encore disponibles, revérifiez car de nouveaux renseignements sur les menaces et du contenu de détection sont continuellement ajoutés.

Analyse de CVE-2026-98432

CVE-2026-98432 affecte le code de gestion des connexions TCP IPv4 dans les noyaux Linux contenant l’implémentation vulnérable introduite dans Linux 4.4. L’équipe CVE du noyau Linux classe le problème comme critique avec un score CVSS 3.1 de 9.8 et le vecteur AV/AC/PR/UI/S/C/I/A.

La vulnérabilité est une condition d’utilisation après libération causée par une concurrence lors du traitement simultané de connexions TCP. Lorsqu’une connexion TCP IPv4 est établie, tcp_v4_syn_recv_sock() transfère les options IP associées à la requête en attente vers le socket nouvellement créé sans en faire une copie séparée.

Un autre CPU peut simultanément traiter un SYN retransmis associé au même socket de requête. Pendant ce processus, les fonctions responsables de la génération du SYN-ACK continuent de lire les options IP tout en étant protégées par une section critique de lecture RCU.

Cependant, le socket enfant peut être détruit alors que cette opération est toujours en cours. Le noyau libère alors la structure inet_opt associée en utilisant kfree(), laissant potentiellement un autre CPU accéder à la mémoire qui a déjà été libérée. La référence obsolète en résultant crée une condition d’utilisation après libération dans ip_options_build().

Une course similaire existe lors de la migration des sockets de requête, y compris les configurations utilisant net.ipv4.tcp_migrate_req=1 ou SK_REUSEPORT_SELECT_OR_MIGRATE basé sur BPF. La correction en amont remplace la libération de mémoire non sécurisée par une libération consciente RCU, garantissant que les lecteurs ont terminé d’accéder à l’objet avant que sa mémoire puisse être récupérée.

Le premier problème affecte spécifiquement l’IPv4. L’avis du noyau indique que l’IPv6 n’est pas vulnérable à cette course particulière car tcp_v6_syn_recv_sock() duplique les options pertinentes au lieu de les transférer de la même manière.

L’exploitation à distance nécessite un trafic réseau spécialement construit et une manipulation précise de la condition de concurrence. Red Hat note que les conséquences probables peuvent inclure un plantage de noyau, une corruption de mémoire et potentiellement une exécution de code à distance. L’absence d’authentification et d’interaction utilisateur augmente considérablement le risque pour les systèmes exposant des services TCP à des réseaux non fiables.

Anthropic a démontré que la vulnérabilité peut être transformée en un exploit root à distance complet. Son modèle de recherche a ciblé un serveur Linux acceptant des connexions Multipath TCP et a utilisé deux étapes pour atteindre l’exécution de commande.

Au cours de la première étape, l’exploit déclenche à plusieurs reprises la condition de concurrence et manipule une valeur de longueur afin que le noyau renvoie de la mémoire adjacente supplémentaire dans une réponse réseau. Finalement, une de ces réponses contient un pointeur de noyau. Cette divulgation révèle des informations sur la disposition de la mémoire du noyau et permet à l’exploit de contourner la Randomisation de l’Espace d’Adresse du Noyau (KASLR).

Au cours de la deuxième étape, l’exploit utilise la même vulnérabilité pour provoquer un débordement de tampon et écraser un pointeur de rappel. Le pointeur est redirigé vers une charge utile précédemment placée en mémoire du noyau en utilisant la fonctionnalité de protocole légitime. Lorsque le noyau invoque le rappel modifié, les fonctions du noyau existantes sont chaînées ensemble jusqu’à ce qu’une commande shell sélectionnée par l’attaquant soit exécutée comme root.

Une caractéristique particulièrement importante de l’exploit est que perdre la course ne fait pas nécessairement planter le serveur. Au lieu de cela, la tentative de connexion peut simplement échouer, permettant à l’attaquant de réessayer à plusieurs reprises. Dans l’environnement de test d’Anthropic, obtenir un pointeur de noyau utile a pris environ 48 minutes, suivies de cinq minutes supplémentaires pour atteindre l’exécution de commande comme root.

Cette démonstration ne doit pas être interprétée comme signifiant que le MPTCP est requis pour l’exploitation. Anthropic a démontré un chemin d’exploitation réussi impliquant un écouteur MPTCP, mais le code vulnérable réside dans le traitement TCP IPv4 ordinaire. Red Hat avertit explicitement que désactiver MPTCP ne résout pas pleinement la vulnérabilité et que les installations par défaut de RHEL restent affectées même si le MPTCP est désactivé par défaut.

La situation de preuve de concept CVE-2026-98432 est également importante à distinguer de l’existence d’un exploit complet militarisé. Anthropic a développé une preuve de concept root à distance fonctionnelle en interne mais ne l’a pas publiée. Le code public rapporté par des chercheurs en sécurité peut démontrer ou détecter des aspects de la course sous-jacente et de la divulgation de mémoire, mais les sources examinées ne documentent pas de code publié publiquement reproduisant la chaîne complète d’exécution de code à distance d’Anthropic.

La vulnérabilité a été signalée par le chercheur d’Anthropic Xinyang Ge. La correction Linux en amont a été appliquée le 5 octobre 2026, tandis que le dossier CVE du noyau Linux a été publié le 15 octobre. Anthropic a décrit publiquement sa recherche complète sur l’exploitation le 27 octobre.

Le projet du noyau Linux identifie les versions corrigées en amont suivantes :

• Linux 5.10.272
• Linux 5.15.223
• Linux 6.1.190
• Linux 6.6.159
• Linux 6.12.113
• Linux 6.18.56
• Linux 7.2.10
• Linux 7.3

L’équipe du noyau recommande de mettre à jour vers le noyau stable le plus récent plutôt que de choisir des validations individuelles.

L’exposition et la remédiation spécifiques à la distribution diffèrent car les fournisseurs Linux maintiennent leurs propres noyaux et rétroportent les correctifs de sécurité. Red Hat évalue actuellement le problème comme critique à 9.8 et a publié des correctifs pour plusieurs flux RHEL 8, 9 et 10. OpenShift et les produits en couches qui dépendent des noyaux RHEL affectés nécessitent également une attention.

Ubuntu évalue également la vulnérabilité comme critique à 9.8. Ubuntu 26.10 a reçu un noyau générique corrigé, tandis que les correctifs pour Ubuntu 22.04 LTS, 24.04 LTS et 26.04 LTS étaient disponibles dans le dépôt de test -proposed début novembre, avec des versions supplémentaires prises en charge en attente de correctifs. Les administrateurs doivent utiliser la page CVE de Canonical plutôt que de se fier uniquement aux numéros de version du noyau en amont.

Pour la détection de CVE-2026-98432, les équipes de sécurité devraient combiner la télémétrie réseau et hôte. Les signaux potentiels de chasse au niveau réseau incluent des paquets TCP IPv4 entrants inhabituels transportant des options IP, en particulier des tentatives de connexion répétées contenant des options Record Route ou Timestamp et des schémas anormaux de retransmission SYN. La présence de ce trafic seul ne confirme pas l’exploitation, mais elle offre un pivot de chasse utile lorsqu’elle est corrélée avec des systèmes vulnérables.

La surveillance au niveau hôte devrait inclure les plantages du noyau Linux, les avertissements du noyau, les indicateurs de corruption de mémoire, les redémarrages inattendus de services, et les activités anormales immédiatement après un trafic réseau suspect. Étant donné que l’exploitation réussie pourrait théoriquement fournir une exécution de code en tant que root, les défenseurs devraient également surveiller les processus privilégiés inattendus, les fichiers nouvellement créés, les modifications de configuration, les mécanismes de persistance, et les connexions sortantes inexpliquées.

Il n’existe actuellement aucun IOC spécifique à l’attaquant pour CVE-2026-98432 tels que des adresses IP malveillantes confirmées, des domaines ou des hachages de logiciels malveillants car les sources examinées n’ont pas signalé d’exploitation réelle. Les défenseurs devraient donc privilégier la détection basée sur les comportements et l’évaluation de l’exposition plutôt que de se fier à des indicateurs statiques.

Mitigation CVE-2026-98432

La rémédiation définitive est d’installer un noyau fourni par le fournisseur contenant le correctif de sécurité. L’équipe CVE du noyau Linux recommande de passer au noyau stable supporté le plus récent, tandis que les utilisateurs de distributions Linux devraient installer les packages fournis spécifiquement par leur fournisseur car les correctifs sont souvent rétroportés sans changer de version du noyau en amont.

Les administrateurs doivent prioriser les serveurs Linux exposés à Internet et les autres systèmes acceptant les connexions TCP IPv4 entrantes. La surface d’attaque est large car la vulnérabilité existe dans la pile réseau du noyau plutôt que dans une application ou un produit serveur individuel.

Les organisations devraient prendre les mesures suivantes :

1. Inventorier les serveurs Linux et identifier le noyau en cours d’exécution avec des outils tels que uname -r.
2. Consulter l’avis de sécurité de la distribution Linux concernée plutôt que de déterminer l’exposition seulement à partir du numéro de version en amont.
3. Installer le noyau corrigé fourni par le fournisseur dès qu’il devient disponible.
4. Redémarrer les systèmes affectés après l’installation du noyau mis à jour pour garantir que le noyau patché est en cours d’exécution.
5. Prioriser les serveurs et infrastructures exposés à Internet acceptant le trafic TCP IPv4 entrant.
6. Examiner les services TCP exposés à l’extérieur et limiter l’accessibilité réseau non nécessaire.
7. Continuer de surveiller les avis des fournisseurs car la disponibilité des correctifs diffère entre les distributions Linux, les variantes de noyau, les noyaux cloud, et les canaux de support.

Red Hat et Ubuntu ont également documenté une approche intérimaire de filtrage des paquets qui rejette les paquets TCP IPv4 entrants contenant des options IP. La condition recommandée de nftables vérifie une longueur d’en-tête IPv4 supérieure à cinq et rejette les paquets TCP correspondants avant qu’ils n’atteignent le chemin de traitement de socket vulnérable.

Cette mesure peut réduire l’exposition car le chemin d’exploitation connu nécessite des options IPv4. Cependant, les deux fournisseurs avertissent que le filtrage des paquets n’est pas un substitut complet à l’installation du noyau corrigé. Il peut également interférer avec des charges de travail qui dépendent légitimement des options IPv4 et doit donc être testé avant le déploiement en production.

Désactiver uniquement le MPTCP ne doit pas être considéré comme une protection suffisante. Bien que l’exploit fonctionnel d’Anthropic ait ciblé un écouteur MPTCP, la vulnérabilité sous-jacente réside dans le traitement normal du TCP IPv4. Red Hat note spécifiquement que RHEL reste vulnérable dans sa configuration par défaut même si le MPTCP est désactivé.

Pour les environnements utilisant des applications Go, désactiver le comportement MPTCP automatique peut réduire l’exposition à l’exploit spécifique démontré par Anthropic, mais cela reste une mesure de réduction de risque incomplète. Les systèmes sans écouteur MPTCP ne devraient pas être automatiquement considérés comme sûrs car d’autres techniques d’exploitation peuvent cibler la même course sous-jacente.

Étant donné qu’aucune campagne de compromission réelle n’a été confirmée, la guidance d’intervention en cas d’incident doit actuellement se concentrer sur l’identification des systèmes potentiellement vulnérables et le comportement d’exploitation suspect plutôt que la recherche d’un ensemble d’infrastructures d’attaquant connu. Les organisations qui observent un trafic TCP inhabituel suivi par une instabilité du noyau ou une exécution privilégiée inattendue devraient traiter l’activité comme potentiellement malveillante et préserver la télémétrie réseau et hôte pour l’analyse.