Un exploit écrit par Claude obtient un root distant sur le TCP du noyau Linux via un écouteur MPTCP

15 octobre 2026. La CVE-2026-98432, un use-after-free dans le traitement du TCP IPv4 présent depuis Linux 4.4, est publiée. 27 octobre 2026. Anthropic révèle qu’un exploit écrit par Claude exécute des commandes en root, sans authentification, sur les serveurs qui écoutent en MPTCP. 29 octobre 2026. L’équipe sécurité de Go publie un avis, parce que les programmes Go 1.24 et ultérieur écoutent en MPTCP par défaut.

Une course entre deux threads au cœur de la poignée de main

La faille est un use-after-free : le noyau lit de la mémoire qu’il a déjà libérée. Elle se joue pendant la poignée de main TCP en trois temps (SYN, SYN-ACK, ACK). Quand le noyau reçoit le premier SYN, il crée un objet temporaire, la request socket, et y range les options IPv4 de l’en-tête (comme Record Route ou Timestamp) dans un champ nommé ireq_opt.

À l’arrivée de l’ACK, la connexion est établie et le noyau crée la socket réelle, dite child socket. Le point critique : la mémoire de ireq_opt n’est pas copiée, le pointeur est simplement transmis à la socket enfant sous le nom inet_opt. Dès lors, la même zone mémoire est référencée par les deux objets.

Si un autre CPU traite entre-temps un SYN retransmis pour la même request socket, il se met à reconstruire le SYN-ACK et lit ces options. Or le destructeur de la socket enfant, inet_sock_destruct(), libérait cette mémoire avec un simple kfree() — immédiatement, sans attendre que les lecteurs en cours aient fini. Résultat : un CPU lit de la mémoire que l’autre vient de libérer. Si cette zone est réallouée à autre chose entre deux lectures de la longueur, les deux lectures divergent, et le noyau peut divulguer de la mémoire ou écrire hors des limites.

La course remonte à octobre 2015, au commit 079096f103fa (« tcp/dccp: install syn_recv requests into ehash table »), qui a retiré le verrou du listener pendant le traitement des request sockets. Linux 4.4, première version à contenir ce commit, ouvre la plage affectée.

Un correctif de deux lignes, mais une correction profonde

Le correctif, signé Eric Dumazet, est le commit e3f33b0a1d89. Il change deux lignes dans net/ipv4/af_inet.c et net/ipv4/tcp_ipv4.c, en remplaçant le kfree() par un kfree_rcu() dans inet_sock_destruct() et tcp_v4_reqsk_destructor() :

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

Le passage à RCU impose d’attendre la fin des lecteurs en cours avant de libérer la mémoire — c’est précisément ce qui manquait. Les autres chemins qui modifiaient les options (do_ip_setsockopt(), cipso_v4_sock_setattr()) utilisaient déjà kfree_rcu() ; seuls ces deux points de destruction de socket libéraient immédiatement.

Les versions corrigées couvrent toutes les branches maintenues : 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10, et 7.3 pour la ligne principale. Le point à retenir : installer le paquet ne suffit pas, il faut redémarrer sur le nouveau noyau — un live patch est un mécanisme séparé.

# Vérifier le noyau en cours d'exécution et l'état de MPTCP
uname -r
sysctl net.mptcp.enabled

Pourquoi l’exploit d’Anthropic change la donne

Ce qui distingue la CVE-2026-98432 d’un use-after-free de plus, c’est la preuve livrée le 27 octobre. Dans son billet « Discovering and exploiting vulnerabilities in critical, real-world software with Claude », l’équipe Frontier Red Team d’Anthropic décrit un exploit qui obtient un root distant sans authentification sur un serveur Linux écoutant en MPTCP.

L’exploit procède en deux temps. Il contourne d’abord la KASLR en exploitant la course pour faire lire au noyau une longueur contrôlée par l’attaquant et renvoyer des octets en trop dans la réponse — si l’un de ces octets contient un pointeur noyau, l’adresse de chargement est déduite. Il détourne ensuite le flux de contrôle en faisant déborder un tampon pour écraser un pointeur de rappel, et enchaîne des appels à des fonctions noyau existantes pour exécuter une commande shell choisie par l’attaquant, en root.

Les ordres de grandeur racontent la persévérance requise : dans la preuve de concept, fuiter un pointeur noyau a pris 48 minutes, atteindre l’exécution de commande 5 minutes de plus. Perdre la course ne fait qu’échouer la poignée de main, sans planter le système — l’attaquant peut donc réessayer jusqu’à réussir. Anthropic précise qu’un modèle de recherche interne non publié a écrit l’exploit après une première amorce.

MPTCP : le prérequis est devenu le réglage par défaut

Le paradoxe de cette faille est qu’elle n’est pas spécifique à MPTCP — la course vit dans le traitement du TCP IPv4. MPTCP est seulement le prérequis démontré par l’exploit. Or ce prérequis est devenu silencieusement banal.

Depuis Go 1.24, les programmes Go écoutent en MPTCP par défaut sur Linux (multipathtcp=2 : activé sur les listeners). Tout service écrit en Go et compilé avec 1.24 ou ultérieur — des API, des proxys, des bases de données — ouvre donc un écouteur MPTCP sans que personne ne l’ait demandé. Le 29 octobre, l’équipe sécurité de Go a publié un avis et ouvert l’issue #82717 proposant de désactiver MPTCP par défaut.

Le contournement provisoire se fait en deux gestes :

# Désactiver MPTCP au démarrage d'un programme Go
GODEBUG=multipathtcp=0 ./serveur

// Ou à la compilation, dans le go.mod du module principal
godebug multipathtcp=0

L’équipe Go le dit elle-même : ce réglage est fragile. Il ne retire que le prérequis démontré, pas la faille — un seul écouteur MPTCP oublié maintient la condition, et il existe peut-être des chemins d’attaque qui ne passent pas par MPTCP. La désactivation de MPTCP est un pansement, pas un correctif.

Où en sont les distributions

Le statut au 30 octobre est inégal, et c’est le point qui doit dicter votre urgence. Debian a corrigé : Debian 12 (bookworm) via linux 6.1.190-1 (DLA-4841-1) et linux-6.12 6.12.113-1~deb12u1 (DLA-4850-1), Debian 13 (trixie) via DSA-6568-1. En revanche, Ubuntu n’était pas encore confirmé corrigé sur son security tracker, et RHEL 8, 9, 10 ainsi qu’OpenShift 4 sont listés comme affectés sans paquet corrigé au moment où nous écrivons. Red Hat note d’ailleurs la faille 8.1 (Important, AC:H), contre 9.8 (Critical) pour le CNA du noyau — un écart qui tient à l’appréciation de la complexité d’attaque, pas à une divergence sur l’impact.

Cet écart de disponibilité a une conséquence concrète : une partie du parc Linux n’a aucun correctif à appliquer ce soir. Pour ces systèmes, le réglage Go et le contrôle de l’exposition MPTCP sont, en attendant, la seule ligne de défense.

Verdict

Si votre distribution propose un noyau corrigé, installez-le et redémarrez maintenant : c’est la seule vraie correction, et le uname -r après redémarrage est la seule preuve que vous êtes protégé. Si vous tournez sous Ubuntu ou RHEL sans correctif disponible, traitez vos services Go 1.24+ comme potentiellement atteignables : dressez la liste de ce qui écoute en MPTCP, appliquez GODEBUG=multipathtcp=0 comme mesure d’attente, et restreignez l’exposition réseau de ces écouteurs en attendant le noyau corrigé. Et ne réduisez pas cette CVE à une histoire d’IA : le fait qu’un modèle ait écrit l’exploit est spectaculaire, mais la leçon opérationnelle est plus banale — une course introduite en 2015 est restée dix ans invisible, et c’est le prérequis devenu réglage par défaut (les écouteurs MPTCP de Go) qui l’a transformée en risque de masse. La CVE-2026-98432 rappelle que, sur un serveur, l’exposition se joue parfois moins dans le code que dans un réglage que personne n’a choisi.

Références

• NVD — CVE-2026-98432
• Anthropic — Discovering and exploiting vulnerabilities in critical, real-world software with Claude (27 octobre 2026)
• LWN — Remote code execution on Linux systems with multipath TCP (30 octobre 2026)
• Commit de correction — e3f33b0a1d89 (Eric Dumazet)
• The Hacker News — Linux Kernel TCP Flaw With 9.8 CVSS Score Affects Ubuntu, Red Hat (29 octobre 2026)
• Go — godebug multipathtcp