Je gère des serveurs Debian en production depuis des années. Chaque fois qu’un CVE sur le kernel sort, je m’arrête pour en lire les détails. Puis je décide s’il faut mettre à jour tout de suite ou attendre. Cette fois, l’histoire est plus compliquée que d’habitude : il y a une vulnérabilité kernel Linux dans le TCP IPv4, un score CVSS contesté entre fournisseurs, et même un exploit root présumé construit par une intelligence artificielle. Commençons par une question qui semble secondaire, mais qui ne l’est pas : qu’est-ce que MPTCP, et pourquoi ça compte même si vous ne l’utilisez pas.
Qu’est-ce que MPTCP et pourquoi ça concerne aussi ceux qui ne l’utilisent pas
Multipath TCP (MPTCP) est le standard RFC 8684. Il étend le TCP classique pour faire circuler une seule connexion sur plusieurs chemins réseau à la fois. Un téléphone peut utiliser le WiFi et le réseau cellulaire au même moment, pour la même connexion. Un serveur avec plusieurs interfaces peut faire pareil, pour la redondance ou pour additionner la bande passante. Apple l’utilise en production depuis iOS 7, en 2013, pour Siri : c’est le cas d’usage réel le plus connu. Certains opérateurs mobiles, par exemple en Corée du Sud, l’exploitent pour le bonding WiFi/LTE. Plusieurs data centers l’adoptent pour le multi-homing entre différents uplinks. Dans le kernel Linux mainline, il est présent depuis la 5.6.
Le point qui m’a fait lever un sourcil est ailleurs. Depuis la version 1.24, les programmes écrits en Go exigent MPTCP par défaut pour les sockets en écoute. Le Go Security Team l’a confirmé le 29 octobre. Et il a donné un avertissement gênant : le bug dont on parle aujourd’hui n’est pas spécifique à MPTCP. Un système sans listener MPTCP actif peut rester quand même exposé à des attaques similaires. Le code vulnérable se trouve dans le chemin TCP IPv4 générique, pas dans un module optionnel. On peut désactiver MPTCP programme par programme, avec la variable GODEBUG=multipathtcp=0 à l’exécution. Mais le Go Security Team qualifie cette mitigation de « fragile » : il suffit d’un seul listener MPTCP resté exposé pour l’annuler. Personne n’a démontré que chaque exploit fonctionnel dépend vraiment de MPTCP. Voilà pourquoi le code MPTCP reste une surface d’attaque, même si vous ne l’activez jamais consciemment dans votre stack : il suffit qu’il soit compilé dans le kernel et atteignable.
Le projet MPTCP lui-même déclare, sur sa propre page, que les principales distributions Linux actuelles livrent le kernel avec le support MPTCP compilé par défaut (CONFIG_MPTCP=y). Il cite explicitement Debian, Ubuntu, RHEL et Fedora. C’est une déclaration du projet lui-même, pas une vérification indépendante distribution par distribution, mais le concept reste valable : le support est activé au niveau du kernel, pas « opt-in » au niveau du système d’exploitation. Seule la négociation par connexion individuelle reste à la charge de l’application.
La vulnérabilité kernel Linux CVE-2026-98432 en bref
Le CVE team du kernel Linux a publié la CVE-2026-98432 le 15 octobre 2026. Le correctif upstream avait déjà été appliqué dix jours plus tôt, le 5 octobre. Il arrive souvent que la publication suive le commit avec un certain retard. Le score CVSS de 9,8 (critique) n’est arrivé que le 24 octobre, neuf jours après la publication de la CVE.
Le problème se situe dans la gestion du handshake TCP pour IPv4, en particulier dans la fonction tcp_v4_syn_recv_sock(). Quand une connexion est créée, les options IP du paquet SYN sont transmises du request socket en attente vers le nouveau socket. Par exemple Record Route ou Timestamp, si le client les inclut dans un SYN forgé. Le problème est qu’elles sont transmises par référence, pas par copie, et sans le lock du listener. Selon l’analyse technique du patch, les structures concernées s’appellent inet_opt et ireq_opt. Un deuxième CPU peut libérer ce buffer avec kfree(), appelé depuis inet_sock_destruct() ou depuis tcp_v4_reqsk_destructor(). Pendant ce temps, un premier CPU est encore en train de le lire dans ip_options_build(), pour construire le SYNACK. C’est un classique use-after-free causé par une race condition. Le chemin IPv6 équivalent, tcp_v6_syn_recv_sock(), copie les options au lieu de les transmettre par référence : il n’est pas vulnérable à la race principale. Il existe aussi une seconde voie d’attaque, via la migration des request-sockets : net.ipv4.tcp_migrate_req=1 ou bien un programme eBPF BPF_SK_REUSEPORT_SELECT_OR_MIGRATE. Les deux sont désactivées par défaut.
Le bug est distant et ne nécessite ni authentification ni interaction de l’utilisateur, selon l’évaluation du kernel team. Il est présent depuis la version 4.4 du kernel. Le correctif est signé par Eric Dumazet, signalé par Xinyang Ge d’Anthropic. Il déplace la libération de la mémoire après une grace period RCU, avec kfree_rcu() : ainsi aucun CPU ne peut plus lire un buffer déjà libéré. Les versions stables corrigées sont 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 et la mainline depuis la 7.3-rc7.
Scores CVSS discordants : les fournisseurs ne sont pas tous d’accord
C’est ici que l’histoire se complique. Le kernel CVE team et Ubuntu évaluent la complexité d’attaque comme basse, et donnent 9,8 (critique). Oracle et SUSE donnent au contraire 8,1 (important) : même vecteur CVSS, mais complexité d’attaque haute. Red Hat, curieusement, a deux évaluations qui ne coïncident pas entre elles. La page CVE publique affiche « Moderate, 5.9 ». Le fichier d’advisory lisible par machine, mis à jour le 29 octobre, affiche au contraire « Important, 8.1 », avec un impact élevé sur la confidentialité et l’intégrité. Le même jour, le bug tracker interne de Red Hat a relevé la sévérité de medium à high. Amazon, de son côté, attribue 7,0. Au moment où j’écris, le NVD n’a pas encore publié son propre score.
Il faut le dire honnêtement. Cette incohérence interne à Red Hat n’est pas un détail que j’ai déduit moi-même : c’est ainsi que la rapporte l’article original de The Hacker News, ma source principale pour ces données. Ce n’est pas la première fois qu’un fournisseur publie deux chiffres différents pour le même bug, sur des canaux différents. Mais ici, le saut de « modéré » à « important » le même jour en dit long. Même pour ceux qui écrivent le code, estimer avec certitude l’exploitabilité réelle d’une race condition dans le kernel est difficile.
État des correctifs : Debian déjà corrigé, d’autres pas encore
C’est le point qui me concerne le plus directement : les hébergements que je gère tournent sur Debian stable. Et ici les faits parlent clairement, sans besoin d’ajouter d’emphase : Debian a déjà corrigé cette vulnérabilité kernel Linux, aussi bien sur trixie que sur bookworm. Debian trixie (stable) a été corrigée le 16 octobre 2026, avec le paquet linux 6.12.113-1, avis DSA-6568-1. Debian 12 (bookworm) a été corrigée en deux étapes : le 17 et le 22 octobre 2026, avec linux 6.1.190-1 (avis DLA-4841-1) et linux-6.12 6.12.113-1~deb12u1 (avis DLA-4850-1). Dans son propre tableau de suivi, Debian ne liste pas de score CVSS séparé pour cette CVE. Elle se limite à indiquer l’état du correctif pour chaque release : c’est l’information qui compte vraiment, pour qui doit décider de redémarrer un serveur.
Comparer cela à l’état d’autres distributions très utilisées aide à donner du poids à la chose. Au 30 octobre, Red Hat a mis à jour l’état de RHEL 8, 9, 10 et OpenShift 4. Avant, c’était « fix deferred » (noté le 29 octobre), maintenant c’est « affected ». Aucune date de sortie n’a été communiquée. Ubuntu, sur toutes les versions supportées (22.04, 24.04, 26.04, 26.10), reste « en cours de traitement », sans date. Ubuntu 16.04, 18.04 et 20.04 sont vulnérables, sans même un correctif listé. SUSE Linux Enterprise Server, de la SP4 à la SP7 plus la 16.0, est dans la même situation. Oracle Linux (UEK), openSUSE Leap 16.0, SUSE Linux Micro 6.2 et Amazon Linux 2023 sont au contraire déjà corrigés. RHEL 7 n’est pas affecté : le chemin de code vulnérable n’a jamais été distribué sur cette release.
Je ne dis pas cela pour faire concurrence à Ubuntu ou RHEL. Ce sont des distributions sérieuses, avec des processus de sécurité robustes. Je le dis parce que sur ce bug précis, dans cette fenêtre temporelle, les faits sont les suivants : ceux qui s’appuient sur des hébergements basés sur Debian stable ont déjà le correctif installé. Sur d’autres distributions très utilisées, en revanche, le serveur reste exposé pendant une durée indéterminée. C’est un avantage concret, vérifiable en regardant les dates. Ce n’est pas une opinion sur le projet Debian en général.
L’exploit (rapporté, non vérifié de façon indépendante) d’Anthropic
La partie la plus inhabituelle de cette histoire concerne Anthropic, l’entreprise qui a signalé le bug en premier via Xinyang Ge. Selon les rapports du secteur, un de ses modèles d’IA internes, non publié publiquement, a construit seul un exploit root fonctionnel. En partant uniquement du patch et du rapport comme prompt. L’attaque en deux phases fonctionnerait ainsi. Dans la première phase, la race fait envoyer à l’attaquant des octets supplémentaires de la réponse du kernel. De là, il récupère une adresse kernel, pour désamorcer KASLR. Dans la seconde phase, le même bug provoquerait un dépassement de buffer. Il écrase un pointeur de callback avec l’adresse d’une charge utile déjà placée en mémoire kernel par l’attaquant. Quand le kernel appelle ce pointeur, la charge utile exécute une commande shell au choix en tant que root. Une race perdue ferait échouer uniquement cette tentative de connexion, sans faire planter le système : des tentatives répétées seraient donc possibles. Dans le test décrit par Anthropic : 48 minutes pour voler l’adresse kernel, 5 minutes supplémentaires pour arriver à l’exécution de commandes.
Red Hat affirme qu’un attaquant distant qui atteint un service TCP exposé peut en général déclencher la race. L’exploit root décrit par Anthropic, cependant, aurait visé spécifiquement des serveurs avec un listener multipath TCP actif. Le billet d’Anthropic ne précise pas si un serveur sans MPTCP est exploitable de la même manière. Ni le record CVE ni le correctif upstream ne mentionnent MPTCP à aucun moment. C’est la presse spécialisée, et non une source primaire, qui rapporte ce lien : je l’écris donc avec le scepticisme qu’il mérite, pas comme un fait établi à cent pour cent. Anthropic n’a publié ni le code de l’exploit, ni la version exacte du kernel utilisée, ni la configuration du serveur cible. Une autre société, Innora, a publié une analyse de la cause racine, avec un environnement de reproduction QEMU. Elle a déclaré qu’elle ne publierait pas d’exploit armé à court terme. Pour l’instant, il n’y a aucune preuve d’exploitation réelle par des fournisseurs ou des CERT. Le bug ne figure pas dans le catalogue CISA KEV, selon la copie mise à jour par le CIRCL du Luxembourg au 28 octobre.
Que faire maintenant sur vos serveurs
Aucun fournisseur n’a publié de contournement officiellement sanctionné pour cette vulnérabilité kernel Linux. Red Hat dit explicitement qu’aucune des mesures qui circulent jusqu’à présent n’atteint son standard de facilité de déploiement et de stabilité. La mitigation principale reste d’appliquer le kernel corrigé et de redémarrer, quand le correctif est disponible pour votre distribution. Sur Debian, c’est déjà le cas. Sur RHEL et Ubuntu, pas encore, au moment où j’écris.
Comme défense en profondeur, pas comme solution définitive, certaines choses ont du sens. Vérifier que net.ipv4.tcp_migrate_req est bien à 0. Contrôler qu’aucun programme eBPF BPF_SK_REUSEPORT_SELECT_OR_MIGRATE n’est chargé. Évaluer un filtrage des paquets IPv4 entrants avec des options Record Route ou Timestamp. Surveiller les éventuels crashs qui citent ip_options_build, ip_build_and_send_pkt ou skb_under_panic. Faire l’inventaire des éventuels listeners MPTCP exposés, en évitant de les laisser atteignables sans raison. Si vous gérez aussi des services contre les attaques applicatives plus courantes, j’ai décrit la même approche dans comment j’ai protégé mes serveurs en attendant le correctif pour PHP2Shell. Atténuer ce qui peut l’être, en attendant le correctif définitif, sans promettre des protections qui n’existent pas.
Pour ceux qui me demandent s’il faut mettre à jour tout de suite : si vous utilisez Debian stable, le kernel corrigé est déjà dans les dépôts de sécurité. La mise à jour est simple, et la fenêtre d’exposition est déjà fermée. Si vous utilisez d’autres distributions, il n’y a pas encore de correctif à installer aujourd’hui. Cela vaut la peine de suivre de près les avis de votre fournisseur dans les prochains jours : la situation évolue rapidement.
Sources : The Hacker News, Debian Security Tracker et le commit du correctif. Debian, Red Hat, Ubuntu et les autres noms cités sont des marques de leurs propriétaires respectifs.
Laisser un commentaire