Linux : une faille MPTCP permettrait une prise de contrôle root à distance

Bleeping Computer a rapporté le 30 octobre 2026 une faille critique du noyau Linux, CVE-2026-98432, située dans le code réseau TCP IPv4. Il s’agit d’un use-after-free, c’est-à-dire l’utilisation d’une zone mémoire déjà libérée, noté 9,8 sur 10 par l’équipe CVE du noyau Linux. Nous ne disposons que de cette source, qui relaie les avis des éditeurs : les points sensibles sont donc présentés au conditionnel.

Une course entre deux cœurs processeur

Le bug viendrait d’une situation de concurrence dans le traitement des demandes de connexion TCP. Quand le noyau transfère au socket enfant les options IP d’une requête sans les copier, un autre cœur peut, au même moment, traiter un SYN retransmis pour la même requête et relire ces options. Un scénario comparable existe lors de la migration des requêtes TCP, si net.ipv4.tcp_migrate_req est activé ou si un programme BPF_SK_REUSEPORT_SELECT_OR_MIGRATE est utilisé.

Aucune authentification n’est requise. Des chercheurs d’Anthropic indiquent qu’un modèle Claude non publié a mis au point un exploit qui contourne le KASLR (la randomisation des adresses du noyau) et exécute des commandes en root sur un serveur doté d’un listener MPTCP, en 53 minutes environ. Red Hat, de son côté, classe la faille comme un risque de déni de service avec un score de 5,9, l’exploitation demandant plus que l’envoi d’un simple paquet malveillant. La démonstration d’Anthropic montre qu’elle peut aller plus loin qu’un plantage du noyau.

Qui est exposé

Les noyaux depuis la version 4.4 seraient touchés, y compris ceux d’Ubuntu, de Red Hat Enterprise Linux et de Rocky Linux. RHEL 7 y échappe, son noyau ne contenant pas le code vulnérable, de même que macOS, qui repose sur le noyau XNU d’Apple.

Le scénario d’exécution de code vise les serveurs qui exposent un listener MPTCP. Multipath TCP permet à une même connexion d’emprunter plusieurs chemins réseau à la fois, typiquement Wi-Fi et réseau cellulaire. La faille concerne aussi les connexions TCP ordinaires, même si aucune exécution de code à distance n’a été démontrée publiquement sans listener MPTCP.

Vérifier si MPTCP tourne sans que vous le sachiez

MPTCP n’est généralement pas activé par défaut dans les applications, mais certaines l’activent d’elles-mêmes. Le cas à surveiller est Go : depuis Go 1.24, le langage active MPTCP par défaut pour les listeners TCP sous Linux, dès que le noyau prend en charge la fonctionnalité.

Concrètement, recensez les services réseau exposés sur vos serveurs et repérez ceux qui sont compilés avec Go 1.24 ou une version plus récente : ce sont les candidats les plus probables. Vérifiez aussi si net.ipv4.tcp_migrate_req est activé ou si des programmes BPF de migration de sockets sont chargés. Et ne concluez pas trop vite : sans MPTCP, le risque démontré baisse, mais la faille reste présente.

Les correctifs, état au 30 octobre

Le correctif est intégré au noyau Linux amont et rétroporté dans les branches maintenues. Les distributions suivent en ordre dispersé :

• Debian : corrigé en 6.1.190-1 pour Debian 12 (Bookworm) et 6.12.113-1 pour Debian 13 (Trixie), ainsi que dans testing et unstable ;
• Ubuntu : 22.04 LTS, 24.04 LTS, 26.04 LTS et 26.10 encore vulnérables, correctifs en cours selon le suivi de Canonical ;
• RHEL : versions 8, 9 et 10 affectées, correctifs prévus dans de prochaines mises à jour ;
• Rocky Linux : versions 8, 9 et 10 affectées, selon CIQ ;
• Oracle Linux, Amazon Linux, SUSE : correctifs publiés pour une partie des noyaux concernés.

Installez le noyau mis à jour dès que votre distribution le publie. D’ici là, restreignez l’accès à vos services à des réseaux ou à des adresses IP de confiance. CIQ conseille aussi de bloquer temporairement les paquets TCP IPv4 qui portent des options IP avant qu’ils n’atteignent le code vulnérable, et a partagé des protections temporaires par pare-feu à cet effet.

Le correctif sera simple à installer. Le plus long sera de découvrir quels services avaient activé MPTCP sans le demander à personne.