Claude a développé un exploit permettant d'obtenir les privilèges root à distance pour une faille TCP de Linux 9.8 qui n'a toujours pas fait l'objet d'un correctif sur RHEL et Ubuntu

Principaux enseignements

• La vulnérabilité CVE-2026-98432 permet à un attaquant distant de provoquer une utilisation après libération de mémoire (use-after-free) lors de la phase d'établissement de la connexion TCP IPv4 sous Linux.
• Selon Anthropic, un modèle Claude non encore publié a permis de le transformer en exploit de type « root » à distance contre les écouteurs MPTCP.
• Upstream a corrigé le problème le 5 octobre, mais les noyaux basés sur RHEL et Ubuntu ne disposent toujours pas des correctifs.
• À partir de la version 1.24 de Go, le protocole MPTCP est activé par défaut sur les sockets d'écoute, mais les versions EL 8, 9 et 10 le laissent désactivé.

En bref

Aller directement à la version longue ↓

Ce qui s'est passé : le 15 octobre 2026, l'équipe CVE du noyau a publié le CVE-2026-98432, une condition de concurrence de type « use-after-free » dans le code gérant les poignées de main TCP IPv4, et lui a attribué un score CVSS de 9,8 le 24 octobre. Le correctif, composé de deux lignes de code, a été appliqué en amont le 5 octobre et figure dans toutes les branches stables maintenues. C'est Xinyang Ge, chercheur chez Anthropic, qui l'a signalée. Aller à cette section →

L'affirmation : Le 27 octobre, Anthropic a déclaré qu'un modèle de recherche interne et non encore publié de Claude avait généré un exploit fonctionnel permettant à un attaquant distant, sans identifiants, d'exécuter des commandes en tant qu'administrateur sur des serveurs Linux équipés d'un écouteur Multipath TCP (MPTCP). Le code de l'exploit, la version du noyau et la configuration testée n'ont pas été rendus publics, et aucune reproduction indépendante n'avait été signalée au 30 octobre. Aller à cette section →

Qui est concerné : tout noyau Linux à partir de la version 4.4 qui n’a pas encore intégré le correctif, sur un serveur acceptant les connexions TCP IPv4. Cela inclut RHEL 8, 9 et 10 ainsi que les distributions dérivées de celles-ci, sans oublier Ubuntu. RHEL 7 et CentOS 7 ne sont pas concernés, et les connexions IPv6 ne déclenchent pas le bug principal. Aller à cette section →

Pourquoi le MPTCP est-il important ? : Les programmes Go développés avec Go 1.24 ou une version ultérieure activent le MPTCP par défaut sur leurs sockets d’écoute. Les versions EL 8, 9 et 10 sont toutefois livrées avec le MPTCP désactivé ; par conséquent, un hôte EL standard ne peut pas ouvrir un écouteur MPTCP à moins que quelqu’un ne l’ait activé. L’équipe de sécurité Go continue d’affirmer que les systèmes dépourvus d’écouteur MPTCP peuvent être vulnérables à des attaques similaires. Aller à cette section →

État des lieux : il ne s’agit pas d’une vulnérabilité « zero-day ». Le correctif a été publié avant l’attribution du numéro CVE, Anthropic n’a pas publié son code d’exploitation, et au 30 octobre, aucune exploitation en milieu réel n’a été signalée et le bug ne figure pas dans le catalogue KEV de la CISA. Debian, Oracle UEK, la plupart des versions prises en charge de SUSE et certains noyaux Amazon Linux ont été corrigés. Red Hat et Ubuntu n’ont pas encore fourni de noyau corrigé et n’ont pas communiqué de date. Le correctif sans redémarrage de KernelCare est disponible pour Debian 13, et des correctifs pour EL 8, 9 et 10 sont en cours de développement sans attendre Red Hat. Aller à cette section →

Au programme aujourd'hui : Vérifiez si l'un de vos serveurs écoute sur le protocole MPTCP. Avec -H Si l'on ne tient pas compte de la ligne d'en-tête, chaque ligne affichée par cette commande correspond à un écouteur MPTCP :

ss -H -lMn

Sur les serveurs ne disposant pas d'un noyau fixe, le rejet des paquets TCP entrants contenant des options IP devrait bloquer le déclencheur documenté, que MPTCP soit activé ou non. Cela n'a pas été testé ; essayez-le donc d'abord dans l'environnement de préproduction. Aller à cette section →

La plupart des failles du noyau accessibles via le réseau comportent une condition particulière : il faut qu’un module soit chargé, qu’un protocole de niche soit activé ou qu’un service, que presque personne n’utilise, soit en cours d’exécution. La faille CVE-2026-98432 se trouve dans le code qui gère les connexions TCP IPv4. Si un serveur accepte ne serait-ce qu’une seule connexion TCP IPv4, ce code s’exécute.

Rien que cela suffirait à justifier qu’on s’intéresse à une vulnérabilité notée 9,8. Ce qui l’a propulsée à la une, c’est l’affirmation d’Anthropic selon laquelle l’un de ses modèles l’aurait transformée en une faille permettant une exploitation à distance des privilèges root sans avoir besoin d’identifiants. Le CVE lui-même avait été publié discrètement douze jours auparavant, parmi les nombreux autres que l’équipe CVE du noyau publie chaque semaine.

Le problème, c'est le calendrier. Upstream a corrigé la faille le 5 octobre. Debian avait publié un noyau corrigé dès le 16 octobre. Red Hat n'en propose toujours pas pour RHEL 8, 9 ou 10, et c'est ce retard, bien plus que l'aspect « IA », qui détermine la durée pendant laquelle les systèmes d'entreprise concernés resteront exposés.

Le déclencheur est un paquet TCP SYN contenant des options IPv4, notamment Enregistrer un itinéraire ou un horodatage. Le trafic normal n'envoie pratiquement jamais ce genre de données, mais rien n'empêche un client de le faire. Le noyau en écoute enregistre ces options avec la demande de connexion en attente, dans ireq_opt.

Une fois la procédure d'établissement de la connexion terminée, tcp_v4_syn_recv_sock() transmet les options au nouveau socket fils sans en faire de copie ; ainsi, le socket de requête et le socket fils pointent désormais vers la même mémoire. Si le client renvoie son SYN au bon moment, un autre processeur peut récupérer ce SYN retransmis et commencer à construire un SYNACK à partir des mêmes options dans ip_options_build(). Si la prise secondaire est démontée entre-temps, inet_sock_destruct() libère les options avec un simple kfree(), et le chemin SYNACK lit de la mémoire qui n'existe plus.

Ce bug remonte au commit 079096f103fa (« tcp/dccp : intégration des requêtes syn_recv dans la table ehash »), ce qui permet de traiter les sockets de requête sans bloquer le verrou de l'écouteur. Ce commit a été intégré à Linux 4.4 en janvier 2016. Red Hat indique que RHEL 7 n'est pas concerné, et CentOS 7 utilise la même version de noyau.

Le corriger La correction d'Eric Dumazet est à peu près la plus minime qui soit en matière de corrections du noyau. Une kfree() dans inet_sock_destruct() dans net/ipv4/af_inet.c et un dans tcp_v4_reqsk_destructor() dans net/ipv4/tcp_ipv4.c devenir kfree_rcu(), de sorte que tout ce qui est encore en train de lire les options ait le temps de terminer avant que la mémoire ne soit libérée. La première est la fonction `free` qui intervient dans le chemin principal, et la seconde concerne le chemin de migration ci-dessous.

Il existe une deuxième méthode, plus restreinte, qui passe par la migration des sockets de requêtes et qui ne s'applique qu'avec net.ipv4.tcp_migrate_req=1 ou un BPF_SK_REUSEPORT_SELECT_OR_MIGRATE programme ci-joint. Les deux sont désactivés par défaut. Si vous avez lu que ce bogue « nécessite une configuration non par défaut », cela ne vaut que pour la voie de migration. La voie principale n'en nécessite aucune.

L'IPv6 contourne le chemin principal car tcp_v6_syn_recv_sock() copie les options. Le Fiche CVE signale également un problème de migration similaire du côté IPv6, limité aux options définies par CALIPSO, et l'amont prévoit un correctif distinct pour celui-ci.

La course est difficile à remporter, mais c'est moins rassurant qu'il n'y paraît. Une course perdue se résume simplement à l'échec de cette seule poignée de main. Cela ne provoque pas de panne du serveur ; un attaquant peut donc continuer à essayer tant que le port reste ouvert.

Anthropic a décrit cette faille dans un article publié le 27 octobre par son équipe Frontier Red Team, en présentant également des chaînes d'exploitation pour Chrome, Safari, Android et Windows. L'article précise que ces travaux ont utilisé un modèle de recherche interne non encore rendu public, et que ce modèle a généré l'exploit Linux après une « invite initiale ».

Anthropic décrit deux étapes. Premièrement, remporter la course amène le noyau à lire un champ de longueur contrôlé par l’attaquant et à copier des octets supplémentaires dans le SYNACK qu’il renvoie ; dès lors qu’une de ces réponses contient un pointeur vers le noyau, le KASLR est contourné. Ensuite, ce même bug provoque un débordement de tampon et écrase un pointeur de rappel avec l’adresse d’une charge utile déjà placée en mémoire du noyau. Lorsque le noyau appelle ce pointeur écrasé, une commande shell choisie par l’attaquant s’exécute en tant que root. Anthropic indique que la fuite d’adresse a pris 48 minutes lors de son test, et que l’exécution de la commande en a pris cinq supplémentaires.

TuxCare n'a pas réussi à reproduire cette faille, et aucune reproduction indépendante et publique n'avait été signalée au 30 octobre. Anthropic n'a pas publié le code, la version du noyau ni la configuration sur laquelle elle a effectué ses tests. L'article ne précise pas non plus si les serveurs ne disposant pas d'un écouteur MPTCP peuvent être piratés de la même manière.

Cette affirmation n'est toutefois pas en contradiction avec ce qu'a déjà écrit l'équipe CVE du noyau. Les notes d'évaluation de l'équipe figurant dans la fiche CVE décrivent comment des options obsolètes provoquent une fuite de mémoire du tas du noyau vers le pair et entraînent des écritures hors limites dans le noyau. La chaîne d'exploitation d'Anthropic correspond en substance à la mise en pratique de cette description.

Le protocole MPTCP permet à une connexion d'utiliser plusieurs chemins réseau simultanément. Sous Linux, une application ne peut en bénéficier qu'en en faisant la demande lors de l'ouverture d'un socket ; c'est pourquoi, pendant des années, la plupart des équipes pouvaient partir du principe qu'elles ne l'utilisaient pas.

Go a changé la donne. Depuis la version 1.24 de Go, les programmes Go sous Linux activent par défaut le protocole MPTCP sur les sockets d'écoute lorsque le noyau le prend en charge. Une passerelle API, un proxy inverse ou un service interne basé sur Go et développé avec la version 1.24 ou une version ultérieure de Go peut héberger un écouteur MPTCP que ses propriétaires n'ont jamais demandé.

C'est une bonne nouvelle pour les boutiques EL. Red Hat livre RHEL avec la prise en charge du MPTCP désactivée, et les versions remaniées sont distribuées de la même manière ; par conséquent, l'activer revient à configurer net.mptcp.enabled=1 vous-même. Sur un hôte EL 8, 9 ou 10 standard, un service Go demande l'utilisation du protocole MPTCP, le noyau refuse, et le service revient discrètement à un écouteur TCP classique. À moins qu'un membre de votre équipe n'ait activé MPTCP, la chaîne démontrée par Anthropic n'a aucune cible à atteindre.

Le 29 octobre, le Équipe de sécurité Go ledit paramètre GODEBUG=multipathtcp=0 dans l'environnement d'un programme désactive cette valeur par défaut lors de l'exécution, et l'ajout de godebug multipathtcp=0 vers le module principal go.mod fait la même chose lors de la compilation. Le code qui appelle SetMultipathTCP sur un net.ListenConfig ou net.Dialer prend le pas sur les deux. L'équipe a également qualifié cette mesure d'atténuation « fragile », car le simple fait qu'un seul écouteur MPTCP reste exposé rend le système vulnérable. Et elle est allée encore plus loin : le bug sous-jacent n'est pas spécifique au MPTCP, et les systèmes ne disposant d'aucun écouteur MPTCP peuvent être vulnérables à des attaques similaires.

Prévoyez tout de même en tenant compte de ce dernier point. Personne n'a encore démontré publiquement qu'il était possible d'obtenir les privilèges root sur un serveur ne disposant pas d'un écouteur MPTCP, et la chaîne d'exploitation présentée en nécessite un. Cependant, le bug lui-même est accessible via n'importe quel écouteur TCP IPv4, et l'équipe Go n'exclut pas d'autres voies d'accès ; par conséquent, un hôte sur lequel MPTCP est désactivé est moins exposé, mais pas pour autant protégé.

Si sysctl net.mptcp.enabled retours 1, les applications installées sur cet hôte peuvent ouvrir des sockets MPTCP. Sous EL 8, 9 et 10, 0 c'est la valeur par défaut. Sur une version relativement récente d'iproute2, ss -H -lMn répertorie les écouteurs MPTCP qui existent réellement, sans la ligne d'en-tête. Si ss rejette le -M drapeau : la version d'iproute2 de cet hôte est trop ancienne pour cette vérification.

Pourquoi les fournisseurs ne parviennent pas à s'accorder sur une note

L'équipe CVE du noyau attribue à la vulnérabilité CVE-2026-98432 une note de 9,8, avec un vecteur d'attaque réseau, aucun privilège et une complexité d'attaque faible. Son raisonnement repose sur le fait que les deux phases de la course sont « provoquées par l'attaquant », puisque ce dernier contrôle le paquet SYN, la retransmission et la fermeture de la connexion. La page d’Ubuntu affiche la même note de 9,8. Au 30 octobre, le NVD n’avait pas encore attribué sa propre note.

Red Hat a commencé par attribuer une note bien inférieure. Sa page CVE avait initialement classé la faille comme « modérée » (5,9), avec un plantage comme conséquence la plus probable et aucun impact démontré sur la confidentialité ou l’intégrité. Le 29 octobre, son fichier d'avis lisible par machine a été reclassé en « Important » (8,1), avec un impact élevé sur la confidentialité et l'intégrité, et dès le 30 octobre, la page CVE affichait le même niveau de 8,1. Oracle, SUSE et Amazon lui attribuent également la note de 8,1.

Tout cet écart qui subsiste se résume à un seul indicateur. Le vecteur 8.1 commun à Red Hat, Oracle, SUSE et Amazon correspond à celui de l’équipe du noyau sur tous les points, sauf en ce qui concerne la complexité de l’attaque, que ces fournisseurs évaluent comme élevée. C’est un argument technique valable dans le cadre d’une course. Cela a moins d’importance lorsque perdre la course ne coûte à l’attaquant rien d’autre qu’une tentative de connexion.

Le problème concret réside dans la mise en œuvre. Si votre scanner ou votre système de gestion des correctifs SLA se base sur le niveau de gravité attribué par le fournisseur, cette faille a pu apparaître sur les hôtes EL comme « modérée », voire pas du tout urgente, pendant la majeure partie du mois d’octobre, malgré l’existence d’une chaîne d’exploitation à distance décrite publiquement. Si votre processus classe les correctifs par niveau de gravité attribué par le fournisseur, passez outre cette classification pour ce CVE.

CloudLinux 9 et 10 utilisent des noyaux AlmaLinux ; ils suivent donc la lignée d’AlmaLinux. Red Hat mentionne ce problème pour RHEL 8, 9 et 10, mais ne donne aucune date de sortie, tout comme Ubuntu.

Si vous compilez vos propres noyaux, le correctif est inclus dans les versions stables mentionnées ci-dessus. L'équipe CVE du noyau recommande de passer à la dernière version stable du noyau plutôt que de sélectionner ponctuellement des correctifs individuels.

Au 30 octobre, Red Hat indique qu'aucune mesure d'atténuation disponible ne répond à ses normes, et qu'aucun autre fournisseur n'en mentionne dans ses avis de sécurité. Les options ci-dessous découlent du fonctionnement du bogue, mais aucune d'entre elles n'a été testée en interne face à une exploitation. Testez-les d'abord sur un hôte de test, et ne considérez aucune d'entre elles comme un substitut à un noyau corrigé.

La solution la plus efficace consiste à rejeter les paquets TCP entrants qui contiennent des options IPv4. Le chemin principal nécessite des options IP dans le paquet SYN ; le trafic TCP normal n’en contient pas, et cette règle ne tient pas compte du fait qu’une application sur l’hôte utilise ou non le protocole MPTCP :

nft add table ip cve_2026_98432
nft add chain ip cve_2026_98432 prerouting '{ type filter hook prerouting priority -300; }'
nft add rule ip cve_2026_98432 prerouting meta l4proto tcp ip hdrlength != 5 drop

Pour annuler cette opération, exécutez la commande suivante : nft delete table ip cve_2026_98432. Cette règle n'est pas conservée après un redémarrage ; veillez donc à l'ajouter à votre configuration de pare-feu persistante si vous décidez de la conserver. Le filtrage des options IP au niveau de la périphérie du réseau peut s'appliquer à tous les hôtes situés en aval, à condition que l'ensemble du trafic destiné à ces hôtes passe effectivement par cette périphérie. L'inconvénient est que tout client TCP envoyant des options IP se retrouve bloqué, mais ce type de trafic est rare.

Les ingénieurs de TuxCare ont examiné la règle, et elle semble correcte. Cependant, en l'absence de preuve de concept publique à lui opposer, il n'y a pour l'instant aucun moyen de la tester.

Deuxièmement, vérifiez que le chemin de migration est fermé. sysctl net.ipv4.tcp_migrate_req devrait revenir 0, ce qui est la valeur par défaut, et l'hôte ne devrait pas avoir de BPF_SK_REUSEPORT_SELECT_OR_MIGRATE programme ci-joint.

Troisièmement, et c'est la solution la plus rapide, désactivez le MPTCP sur tous les hôtes qui n'en ont pas besoin. Exécutez la commande sysctl -w net.mptcp.enabled=0, et mettre net.mptcp.enabled = 0 dans un fichier situé sous /etc/sysctl.d/ pour que cela reste ainsi. Les versions EL 8, 9 et 10 sont déjà livrées ainsi ; cela concerne donc principalement les distributions qui conservent la valeur par défaut fournie par l'amont, à savoir 1, ainsi que sur les serveurs EL où quelqu'un a activé le MPTCP. Redémarrez les services qui ont déjà ouvert des écouteurs MPTCP afin qu'ils repassent en TCP standard. Pour les services Go, GODEBUG=multipathtcp=0 Il fait la même chose pour chaque programme. Cela supprime les besoins de la chaîne de l'écouteur Anthropic, mais cela ne corrige pas le bug.

Si un serveur est accessible depuis Internet et ne dispose pas d'un noyau fixe, commencez par vérifier net.mptcp.enabled et en désactivant MPTCP si personne n’en a besoin. Il s’agit d’un seul paramètre sysctl, facile à annuler, qui supprime le listener dont dépend la chaîne présentée. La règle relative aux options IP constitue la couche suivante à évaluer. Testez-la en environnement de préproduction, vérifiez qu’elle supprime ce que vous souhaitez sans causer de dysfonctionnement, puis décidez de la déployer ou non. Dans tous les cas, donnez la priorité à cet hôte pour l’installation d’un noyau corrigé. Si votre distribution fournit déjà un noyau corrigé, installez-le, puis redémarrez ou appliquez le correctif sans redémarrage, et ignorez les solutions de contournement.

Vérifier un serveur en moins d'une minute

Cinq commandes permettent de répondre à la plupart des questions :

uname -r
sysctl net.mptcp.enabled net.ipv4.tcp_migrate_req
ss -H -lMn
nft list table ip cve_2026_98432
kcarectl --patch-info | grep 'CVE-2026-98432'

La première ligne indique le noyau en cours d'exécution, mais les noyaux EL et Ubuntu comportent des portages dont le numéro de version ne permet pas de les identifier ; vous devez donc comparer le paquet du noyau installé avec l'avis de sécurité de votre fournisseur et le tableau ci-dessus. A 1 pour net.mptcp.enabled ce qui signifie que les applications peuvent ouvrir des sockets MPTCP, et net.ipv4.tcp_migrate_req devrait être 0, la valeur par défaut. Chaque ligne ss -H -lMn prints est un écouteur MPTCP. Le nft Cette ligne affiche le tableau et ses règles s’ils sont chargés, ce qui vous permet de vérifier que la règle de suppression est bien présente ; la dernière ligne indique quant à elle si KernelCare a appliqué son correctif sans redémarrage pour cette vulnérabilité CVE. Il s’agit là d’indicateurs rapides, et non d’un test de sécurité complet. Pour un parc de machines, exécutez ces mêmes lignes via l’outil qui gère déjà vos commandes ad hoc, qu’il s’agisse d’Ansible, de Salt ou simplement de ssh en boucle.

La position de KernelCare

Le correctif sans redémarrage de KernelCare pour la vulnérabilité CVE-2026-98432 est désormais disponible pour Debian 13, à la fois dans les dépôts « production » et « ePortal ». Les correctifs pour Debian 12 et Oracle Linux UEK sont en cours de développement. Le correctif en amont est mineur et ne modifie aucune structure de données ; TuxCare n’attend donc pas Red Hat. Des correctifs sans redémarrage pour les noyaux EL 8, 9 et 10 sur RHEL, AlmaLinux, CloudLinux, Oracle Linux RHCK et Rocky Linux sont en cours de compilation, et le CVE Tracker les affichera dès leur publication. Les correctifs pour Ubuntu ne sont pas encore disponibles, et aucune date n’est pour l’instant communiquée.

Sous Debian 13, les serveurs bénéficiant des mises à jour automatiques de KernelCare reçoivent le correctif selon leur calendrier habituel ; vous pouvez également le récupérer immédiatement à l'aide de la commande suivante : kcarectl --update. Aucun redémarrage n'est nécessaire. Vérifiez que l'installation s'est bien effectuée à l'aide de kcarectl --patch-info | grep 'CVE-2026-98432'. Le Suivi des vulnérabilités CVE de TuxCare affiche l'état des correctifs ne nécessitant pas de redémarrage pour chaque distribution, au fur et à mesure des mises à jour.

Procurez-vous KernelCare dès aujourd’hui →

La solution a été mise en place en premier, mais elle n'est toujours pas suffisante

Au regard des critères habituels, cette publication s'est bien déroulée, mais elle laisse encore de nombreux serveurs Linux d'entreprise dans l'attente.

La divulgation coordonnée a rempli son rôle en amont. Le correctif a été déployé avant la publication du CVE, le CVE a été rendu public avant que quiconque ne revendique un exploit, et le code d'exploitation lui-même est resté confidentiel. Personne ne peut qualifier cela de « zero day ».

Rien de tout cela n’aide un serveur web RHEL 9 dont le port 443 est ouvert. Un correctif en amont de deux lignes doit encore être intégré au noyau du fournisseur, puis devenir un paquet distribué, avant d’être appliqué via un redémarrage ou un correctif sans redémarrage sur chaque hôte exposé. Pour RHEL et les distributions qui le recompilent, cette première étape n’avait pas encore eu lieu au 30 octobre. Entre-temps, un article rendu public décrit désormais la structure d’une chaîne d’exploitation fonctionnelle et la durée de chaque étape. Le code est resté confidentiel, mais l’approche, elle, a été divulguée, et la prochaine tentative n’aura pas à repartir de zéro.

Vérifiez donc quels hôtes disposent d’écouteurs MPTCP, en particulier ceux écrits en Go, et désactivez MPTCP partout où cela n’est pas nécessaire. Testez la règle « IP options » en environnement de préproduction, et si elle fonctionne correctement, envisagez de l’appliquer aux serveurs exposés à Internet qui ne disposent pas d’un noyau fixe. Surveillez ensuite la disponibilité des noyaux fixes proposés par votre distribution et déterminez à quelle vitesse vous pouvez les déployer sur chaque hôte exposé — via un correctif sans redémarrage ou par redémarrage, selon ce que votre parc de serveurs est réellement en mesure de supporter.

Procurez-vous KernelCare dès aujourd’hui →

Sources

Les sources principales de cet article sont l'annonce CVE du noyau, la fiche CVE et le correctif en amont, ainsi que les pages des éditeurs Red Hat (notamment son avis de sécurité et son outil de suivi des bogues), Ubuntu, Debian, Oracle, Amazon et SUSE. Sont également cités l'article d'Anthropic, l'annonce de l'équipe de sécurité Go, la documentation GODEBUG de Go, la documentation MPTCP du noyau, l'entrée NVD, l'article de The Hacker News, ainsi que les archives des versions KernelCare de TuxCare au 30 octobre 2026.