Root à distance sur Linux : une faille TCP, un exploit écrit par une IA

7 novembre 2026 par Benoit

Ou : Comment une course réputée difficile à gagner se gagne en 48 minutes, à force de recommencer

Le 27 octobre 2026, l’équipe Frontier Red Team d’Anthropic a décrit cinq chaînes d’attaque écrites par un modèle de recherche interne, non publié¹. La cinquième vise Linux : après une sollicitation initiale, le modèle a écrit un exploit qui exécute une commande en root sur un serveur distant, sans identifiant ni action de la victime. 48 minutes pour faire fuir une adresse du noyau, cinq de plus pour la commande. La faille, CVE-2026-98432, est une utilisation de mémoire après libération dans l’ouverture des connexions TCP en IPv4, présente depuis Linux 4.4, sorti en janvier 2016. L’équipe CVE du noyau lui donne 9,8 sur 10². Le correctif tient en deux lignes. Au 3 novembre 2026, Debian, Oracle Linux et Red Hat Enterprise Linux (RHEL) distribuent un noyau corrigé ; Ubuntu teste encore le sien.

Le billet donne les étapes, pas la recette : ni code, ni version du noyau, ni configuration. Des failles du noyau, il y en a toujours eu. Ce qui change, c’est le prix de l’exploit, donc le temps entre « il y a un bug » et « quelqu’un a un shell root ».

Faille TCP IPv4 du noyau Linux : ce que corrige CVE-2026-98432 et comment protéger ses serveurs

Deux lignes, à onze ans moins un jour

Le 2 octobre 2015, Eric Dumazet, l’un des mainteneurs de la pile réseau et de TCP dans Linux, a changé la façon dont le noyau traite les connexions en cours d’ouverture : il les gère sans verrouiller la socket qui écoute³. Son message promettait deux fois moins de pression sur ce verrou. C’était aussi, on le sait maintenant, la porte d’une course entre deux processeurs. Le 1er octobre 2026, le même développeur a écrit le correctif, en créditant Xinyang Ge, d’Anthropic, pour le signalement⁴.

D’après la fiche CVE, le noyau garde les options de l’en-tête IPv4 reçues avec le premier paquet d’une connexion, et la socket créée à l’établissement en hérite sans les copier. Si le client renvoie ce premier paquet, un autre processeur peut encore lire ces options pour répondre, alors que la socket, refermée entre-temps, les a libérées.

C’est un vestiaire avec deux employés et un seul ticket. Le premier rend le manteau et réattribue le crochet. Le second, qui lisait encore le ticket, va au même crochet et rapporte ce qui y pend maintenant. Le correctif fait attendre la fin de toutes les lectures en cours avant de rendre la mémoire :

1
2

-	kfree(rcu_dereference_protected(inet->inet_opt, 1));
+	kfree_rcu(rcu_dereference_protected(inet->inet_opt, 1), rcu);

kfree() libère tout de suite ; kfree_rcu() attend que plus aucun lecteur ne tienne le pointeur. IPv6 échappe au premier scénario : il copie les options².

48 minutes de fuite, cinq de plus pour le root

Le billet décrit deux étapes. La première contourne KASLR, le placement aléatoire du noyau en mémoire : la course fait lire au noyau une longueur choisie par l’attaquant, et il renvoie des octets en trop, jusqu’à ce que l’un des envois contienne une adresse du noyau. La seconde détourne le flot d’exécution, jusqu’à une commande lancée en root¹.

Le détail qui compte est ailleurs : une course perdue fait seulement échouer l’ouverture de la connexion, sans faire tomber la machine. L’attaquant recommence autant qu’il veut. Fin octobre, Red Hat notait la faille 5,9, la course étant jugée difficile à gagner, puis 8,1, selon The Hacker News⁵. Au 3 novembre, sa fiche affiche 9,8, gravité critique ; Oracle Linux en est encore à 8,1⁶. Et contrairement à l’accès root par Tailscale SSH, qui partait d’une machine déjà compromise, le paquet arrive ici avant toute authentification.

MPTCP, la porte que l’exploit a prise

L’exploit vise un serveur qui écoute en MPTCP, l’extension qui permet à une connexion TCP d’emprunter plusieurs chemins réseau à la fois⁷. Ni la fiche CVE ni le correctif n’en parlent. Red Hat écrit que MPTCP n’est pas une condition de la faille, et l’équipe sécurité de Go juge fragile de le couper programme par programme : ce serait supposer que tous les exploits passent par là⁸. Couper MPTCP n’est pas une défense prouvée.

Savoir s’il est actif reste utile, et la réponse surprendra les développeurs Go. Depuis Go 1.24, net.Listen écoute en MPTCP par défaut sous Linux, et le noyau l’accepte par défaut⁹. Un service Go exposé sur un serveur écoute donc en MPTCP sans que personne l’ait demandé.

1
2
3
4

uname -r                    # le noyau qui tourne, pas forcément le dernier installé
sysctl net.mptcp.enabled    # 1 : le noyau accepte les sockets MPTCP
ss -Mln                     # les sockets MPTCP en écoute
GODEBUG=multipathtcp=0 ./mon-service   # Go : écoute en TCP classique

Avec GODEBUG=multipathtcp=0, un petit serveur compilé avec Go 1.27.3 disparaît bien de ss -Mln. L’option existe aussi dans le go.mod, et un appel à SetMultipathTCP passe outre⁸. Côté noyau, net.mptcp.enabled vaut par espace de noms réseau : le mettre à 0 sur l’hôte ne couvre pas les conteneurs qui ont le leur⁹.

Où en sont les distributions au 3 novembre 2026

En attendant, Ubuntu et Red Hat décrivent une règle nftables qui rejette les paquets TCP IPv4 porteurs d’options IP, en prévenant qu’elle réduit le risque sans l’éliminer. L’équipe sécurité d’Ubuntu tient la mise à jour pour la seule parade appropriée¹⁰. Au 3 novembre, la faille ne figure pas au catalogue des failles exploitées de la CISA, l’agence américaine de cybersécurité¹¹.

Ce que fait celui qui gère trois serveurs

D’abord, connaître son noyau : uname -r donne celui qui tourne, dpkg -l 'linux-image-*' | grep '^ii' ceux qui sont installés sur Debian et Ubuntu. Une mise à jour installe le nouveau ; l’ancien tourne jusqu’au redémarrage.

Ensuite, lire la ligne de sa version dans le traqueur de sa distribution, pas dans la presse. En une semaine, RHEL est passé d’aucun noyau corrigé à trois, et son score de 5,9 à 9,8. Les articles du 30 octobre avaient raison le 30 octobre.

Enfin, redémarrer. L’avis de Red Hat le dit sans détour : la mise à jour ne prend effet qu’après un redémarrage¹². Le correctif à chaud, Livepatch chez Ubuntu ou kpatch chez Red Hat, l’éviterait, mais au 3 novembre aucune des deux fiches n’en annonce pour cette faille. C’est le vrai prix d’un VPS : l’heure de maintenance. Cette semaine, elle tient en une mise à jour et un redémarrage.

DevOps Dave : J’ai coupé MPTCP sur les trois serveurs. On est tranquilles.

Security Sarah : La faille est dans TCP IPv4. MPTCP, c’est la porte qu’a prise l’exploit d’Anthropic. Rien ne dit que c’est la seule.

DevOps Dave : J’ai aussi fait la mise à jour hier soir.

Security Sarah : Et uname -r ?

DevOps Dave : … L’ancien.

Security Sarah : Tu as acheté la serrure. Elle est encore dans son carton.

Le délai qui raccourcit

Mandiant mesure le délai moyen avant qu’une faille soit exploitée, avant ou après son correctif : 63 jours en 2018 et 2019, 32 en 2021 et 2022, cinq en 2023 hors valeurs aberrantes, 47 en les gardant¹³. Anthropic écrit que combiner des failles en un exploit fonctionnel était l’affaire de quelques équipes spécialisées, et qu’un modèle le fait désormais avec peu d’intervention humaine¹.

Ici, l’exploit a été écrit par ceux qui ont signalé la faille, et ils l’ont gardé pour eux : leur politique laisse 90 jours pour corriger, puis 45 avant d’en dire plus que l’avis public. Rien n’oblige le prochain à faire de même. L’Europe donne déjà 24 heures à un éditeur pour signaler une faille exploitée. Pour appliquer un correctif du noyau, personne ne fixe de délai à celui qui gère trois serveurs. Personne, sauf l’attaquant.

La course était difficile à gagner. Elle n’a jamais été difficile à recourir.

À lire aussi