Une erreur de gestion mémoire dans la pile TCP du noyau Linux, référencée CVE-2026-98432 et notée 9,8 sur 10 par l’équipe CVE du noyau, peut offrir à un attaquant distant les pleins pouvoirs sur un serveur. Le sujet a pris une ampleur particulière parce que c’est un modèle d’IA d’Anthropic, non commercialisé, qui a construit l’attaque fonctionnelle. Les correctifs existent dans le noyau officiel, mais plusieurs grandes distributions ne les livraient pas encore le 30 octobre.
Ce que fait la faille, en clair
Il s’agit d’une utilisation de mémoire après libération (« use-after-free ») dans le code qui gère l’établissement des connexions TCP en IPv4. Selon BleepingComputer, le problème vient d’une situation de concurrence : lors de la création d’une nouvelle socket, les options IP de la demande de connexion lui sont confiées sans être recopiées. Si un cœur du processeur libère ces données pendant qu’un autre s’en sert encore, ce dernier lit une zone mémoire qui ne lui appartient plus, explique How-To Geek.
Le défaut est ancien : il remonte à la version 4.4 du noyau et touche huit branches maintenues. Les versions corrigées citées par How-To Geek sont les 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 et 7.3-rc7.
Le rôle de l’IA d’Anthropic
D’après ShiftDelete.Net, l’équipe « Frontier Red Team » d’Anthropic a publié ses travaux le 27 octobre. Un modèle de recherche non publié y a écrit une preuve de concept qui obtient, sans mot de passe ni action de la victime, l’exécution de commandes en tant que root sur un serveur Linux disposant d’un service MPTCP (TCP multichemin) en écoute. Le média détaille deux étapes : environ 48 minutes pour gagner la course et récupérer une adresse du noyau, ce qui contourne la protection KASLR, puis environ cinq minutes pour détourner le flot d’exécution. Une tentative ratée ne fait pas planter la machine, ce qui permet de recommencer.
Ces chiffres doivent être lus avec prudence. Le code de l’attaque n’a pas été publié, et les articles ne décrivent pas la configuration de test. Red Hat juge l’exploitation complexe et attribue une note inférieure à 9,8 : 5,9 selon BleepingComputer, qui précise que l’éditeur y voit surtout un risque de déni de service, et 8,1 en note provisoire selon ShiftDelete.Net. Aucune exploitation réelle n’avait été signalée à la date des articles.
Qui est concerné
MPTCP n’est généralement pas activé par défaut dans les applications. Mais BleepingComputer relève un piège : depuis la version 1.24 du langage Go, les services TCP écrits en Go l’activent automatiquement sous Linux quand le noyau le permet. Des administrateurs peuvent donc exposer un service MPTCP sans le savoir. Surtout, le défaut se situe dans le traitement TCP IPv4 ordinaire : la démonstration publique exige MPTCP, pas la faille elle-même.
Côté distributions, la situation était contrastée au 30 octobre, selon BleepingComputer :
- Debian a publié des noyaux corrigés pour Debian 12 et Debian 13 ;
- Oracle Linux, Amazon Linux et SUSE ont livré des correctifs pour une partie de leurs versions ;
- Ubuntu 22.04, 24.04, 26.04 et 26.10 restaient vulnérables, correctifs en préparation ;
- RHEL 8, 9 et 10, ainsi que Rocky Linux, sont touchés ; RHEL 7 ne l’est pas.
Les postes macOS ne sont pas concernés, puisqu’Apple utilise son propre noyau.
Que faire en attendant le correctif
La seule réponse durable est d’installer un noyau corrigé puis de redémarrer : un paquet mis à jour ne protège pas tant que l’ancien noyau tourne. Il faut donc vérifier la version réellement chargée, et pas seulement l’écran des mises à jour. En attendant, plusieurs mesures réduisent l’exposition :
- recenser les services en écoute, en particulier ceux écrits en Go, et vérifier s’ils utilisent MPTCP ;
- limiter l’accès aux serveurs à des réseaux ou adresses de confiance ;
- bloquer temporairement au pare-feu les paquets TCP IPv4 porteurs d’options IP, comme le recommande l’éditeur CIQ cité par BleepingComputer.
BleepingComputer souligne que désactiver MPTCP seul ne suffit pas, puisque du trafic TCP classique peut aussi déclencher le défaut. Pour les PME qui louent des serveurs virtuels, le plus simple reste de demander à l’hébergeur quand le noyau corrigé sera disponible et de planifier le redémarrage.
Ce que l’épisode change
Au-delà de la faille, l’affaire illustre l’accélération de la recherche offensive par l’IA. Un modèle capable d’enchaîner fuite mémoire, contournement de protection et prise de contrôle en moins d’une heure raccourcit le délai entre la publication d’un correctif et l’apparition d’attaques. Pour les équipes informatiques, cela plaide pour des cycles de mise à jour du noyau plus courts et pour des outils de correction à chaud, quand ils sont disponibles.
Questions fréquentes
Mon serveur est-il vulnérable s’il n’utilise pas MPTCP ?
Le défaut se trouve dans la gestion TCP IPv4 classique, donc le noyau reste vulnérable tant qu’il n’est pas corrigé. L’attaque démontrée par Anthropic visait toutefois un serveur avec un service MPTCP en écoute ; aucune prise de contrôle n’a été publiquement montrée sans lui.
La faille est-elle déjà exploitée par des pirates ?
Non, aucune attaque réelle n’avait été rapportée au 30 octobre, et le code d’Anthropic n’est pas public. La médiatisation du sujet rend néanmoins probable l’apparition d’outils d’attaque, d’où l’intérêt de corriger vite.
Comment savoir si mon noyau est corrigé ?
Il faut comparer la version du noyau en cours d’exécution aux versions corrigées publiées par votre distribution, puis redémarrer après l’installation. Une mise à jour installée sans redémarrage laisse l’ancien noyau actif.
Sources
- Critical Linux kernel flaw allows remote root attacks on MPTCP servers — BleepingComputer, 2026-10-30
- Anthropic's Claude AI found a critical Linux flaw that could give hackers root access — How-To Geek (via Yahoo Tech), 2026-10-30
- Claude Linux Exploit Gets Remote Root on Servers in 53 Minutes — ShiftDelete.Net, 2026-10-30