CVE-2026-98432 : la faille critique du noyau Linux qui peut offrir un accès root à distance

Notée 9,8 sur 10, la faille CVE-2026-98432 présente dans le noyau Linux permettrait, selon Anthropic, d'exécuter des commandes à distance en tant que root, le tout sans être authentifié. Quels sont vraiment les risques ? Comment se protéger ? Voici ce qu'il faut savoir.

Cette vulnérabilité se situe dans le code qui établit les nouvelles connexions TCP en IPv4. Pour rappel, une connexion TCP s'ouvre par une poignée de main en trois temps : le client envoie un SYN, le serveur répond par un SYN-ACK, puis le client confirme avec un ACK. Si la réponse tarde, le client renvoie son SYN. Un paquet IPv4 peut aussi transporter des options IP, des champs facultatifs ajoutés à son en-tête, que le serveur garde en mémoire pendant cette poignée de main.

C'est là que la faille de sécurité se situe. Une fois la connexion établie, la fonction tcp_v4_syn_recv_sock() confie ces options au nouveau socket sans en faire de copie : la requête en attente et le socket pointent vers la même zone mémoire. Si ce socket est détruit, la zone est libérée, alors qu'un autre cœur du processeur peut encore être en train de la lire pour répondre à un SYN retransmis. Le noyau lit alors une mémoire qui ne lui appartient plus : c'est un cas de use-after-free. Pour faire simple, imaginez deux collègues qui consultent la même fiche : l'un la passe au broyeur pendant que l'autre la lit encore. Et si un attaquant parvient à placer ses propres données à cet emplacement entre-temps, c'est ce contenu que le noyau risque d'utiliser. IPv6 n'est pas concerné par ce scénario, car les options y sont copiées pour chaque socket.

La découverte de cette vulnérabilité est à mettre au crédit de Xinyang Ge, chercheur chez Anthropic. Le 27 octobre 2026, l'entreprise a publié un article de son équipe Frontier Red Team qui détaille cinq chaînes d'exploitation produites par Claude avec un modèle interne non publié, dont une sur Linux. Cela montre une fois de plus le rôle de l'IA dans la découverte de failles de sécurité...

Le bug lié à cette faille de sécurité a été introduit dans Linux 4.4, d'après l'annonce de l'équipe CVE du noyau Linux. Le correctif, qui retarde la libération de ces options, est intégré à plusieurs versions du noyau Linux : 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 et 7.3.

Un accès root à distance via MPTCP, que Go active par défaut

D'après Anthropic, l'exploit vise les serveurs Linux avec un listener MPTCP (multipath TCP, qui permet à une connexion d'emprunter plusieurs chemins réseau). Il se déroule en deux temps :

• Contournement de KASLR : en déclenchant le bug au bon moment, l'attaquant pousse le noyau à lui renvoyer des octets en trop. Dès qu'une réponse contient une adresse mémoire du noyau, l'attaquant sait où se trouvent ses éléments en mémoire, ce qui neutralise KASLR, la protection qui rend ces adresses aléatoires.

• Détournement du flux d'exécution : le même bug sert à écraser un pointeur de callback avec l'adresse d'une charge utile déjà déposée en mémoire noyau. Une commande shell est alors exécutée en root.

"Une tentative ratée fait seulement échouer la poignée de main", précise Anthropic. C'est le cas où la race condition n'est pas satisfaite. Ce qu'il faut comprendre, c'est qu'un échec ne fait pas planter le serveur : l'attaquant peut donc multiplier les tentatives jusqu'à tomber sur le bon timing. Lors du test d'Anthropic, il a fallu 48 minutes pour récupérer une adresse du noyau, puis 5 minutes de plus pour exécuter la commande en root. Anthropic n'a publié ni le code de l'exploit, ni la version du noyau, ni la configuration testée.

On pourrait croire MPTCP marginal, puisqu'une application doit le demander explicitement à l'ouverture de son socket. Sauf que depuis Go 1.24, les programmes Go le font d'eux-mêmes : la documentation de Go indique que MPTCP est activé par défaut sur les sockets en écoute. Le 29 octobre, l'équipe de sécurité de Go l'a rappelé dans un message public, en précisant que le bug n'est pas propre à MPTCP : des systèmes sans listener MPTCP peuvent eux aussi être vulnérables. Go étant un langage très utilisé, y compris pour des outils d'infra, cela signifie qu'il y a peut-être plus de machines exposées à cette vulnérabilité qu'on ne le pense... Pour le vérifier sur une machine, la commande ss -lM liste les sockets MPTCP en écoute.

Cette faille a pu être sous-estimée dans un premier temps, et le comportement de Red Hat est d'ailleurs représentatif. Le 29 octobre, Red Hat avait associé une note de 5,9 sur 10 et une sévérité modérée à cette faille de sécurité. Depuis, l'information a été révisée : cette faille est désormais associée à un score de 9,8 sur 10 et elle est considérée comme critique. La faille "permet à un attaquant distant non authentifié de provoquer une corruption de la mémoire du noyau ou un plantage immédiat du système.", écrit Red Hat.

Quel noyau installer pour se protéger ?

Voici l'état des lieux au 2 novembre 2026 :

• RHEL : correctifs publiés le 1er novembre pour RHEL 8 (kernel-4.18.0-553.182.1.el8_10), RHEL 9 (kernel-5.14.0-687.64.1.el9_8) et RHEL 10 (kernel-6.12.0-211.72.1.el10_2). Le noyau temps réel de RHEL 9 et RHEL CoreOS (OpenShift) restent affectés.

• AlmaLinux 8, 9 et 10 : noyaux corrigés disponibles depuis le 30 octobre, mais uniquement dans le dépôt de test, d'après le blog d'AlmaLinux.

• Debian : corrigé sur Debian 13 (linux 6.12.113-1) et Debian 12 (linux 6.1.190-1 ou linux-6.12 6.12.113-1~deb12u1). Pour les versions antérieures, voir ci-après.

• SUSE : SLES 15 SP4 à SP6 LTSS, SLES 16, SLE Micro 5.3 à 5.5, SUSE Linux Micro 6.2 et openSUSE Leap 16.0 sont corrigés. SLES 15 SP7 est en cours de validation, SUSE Linux Micro 6.0 reste affecté.

• Amazon Linux 2 et 2023 : tous les paquets noyau sont corrigés depuis le 30 octobre. Le bulletin d'AWS détaille aussi l'état de ses services managés (EKS, ECS, Bottlerocket, RDS...).

• Oracle Linux : noyaux UEK corrigés depuis le 16 octobre.

• Proxmox VE : correctif intégré au noyau proxmox-kernel-7.0.14-25-pve, d'après le bulletin de sécurité publié le 31 octobre.

• Ubuntu : toujours aucun noyau corrigé. La page de Canonical indique un correctif en préparation pour les versions 22.04 à 26.10, tandis que 20.04 et les versions plus anciennes restent listées comme vulnérables.

Et les versions de Debian en fin de vie ? Debian 9, 10 et 11 ne reçoivent plus de mises à jour de sécurité de la part du projet Debian, le support LTS de Debian 11 ayant pris fin le 31 août 2026. La société ScalarX annonce avoir adapté le correctif à leurs noyaux et publie des paquets pour l’architecture amd64 via un dépôt APT signé : 4.9.320-2+sx1 pour Debian 9, 4.19.316-1+sx1 pour Debian 10 et 5.10.262-1+sx1 pour Debian 11. ScalarX précise que ces paquets ne corrigent que la CVE-2026-98432.

En attendant le patch : filtrer les options IPv4

Pour les machines qui ne peuvent pas encore être mises à jour ou redémarrées, Red Hat a publié un bulletin de sécurité avec une règle nftables qui supprime les paquets TCP IPv4 porteurs d'options IP, à l'origine du déclenchement de cette faille. Le champ hdrlength correspond à la longueur de l'en-tête IPv4, exprimée en mots de 32 bits : au-delà de 5 (soit 20 octets), l'en-tête contient des options, ce qui reste rare dans le trafic légitime.

table inet cve_2026_98432 {
    chain input {
        type filter hook input priority -310; policy accept;
        ip protocol tcp ip hdrlength > 5 counter drop
    }
}

Le fichier se charge avec nft --file cve-2026-98432.nft, et la table se supprime avec nft delete table inet cve_2026_98432 une fois le noyau corrigé.

Deux mesures complémentaires sont aussi évoquées par AWS, AlmaLinux et l'équipe de Go :

• Désactiver MPTCP : si vous n'utilisez pas cette fonctionnalité, sysctl -w net.mptcp.enabled=0 l'empêche pour les nouveaux sockets. Pensez à rendre ce réglage persistant via un fichier dans /etc/sysctl.d/ et à redémarrer les services déjà en écoute.

• Côté Go : la variable d'environnement GODEBUG=multipathtcp=0 désactive MPTCP par défaut pour un programme. La directive godebug multipathtcp=0 dans le fichier go.mod fait de même au moment de la compilation.

Aucune de ces mesures ne remplace le correctif. "La meilleure correction pour cette vulnérabilité est de passer à une version corrigée du noyau", insiste l'équipe de Go, qui juge cette solution temporaire fragile : un seul listener MPTCP oublié suffit à laisser le système exposé.

Au 30 octobre, la faille ne figurait pas dans le catalogue KEV de la CISA, et aucune exploitation dans la nature n'a été signalée à ce jour.

Ajouter IT-Connect à mes
sources préférées

Cofondateur d'IT-Connect et Microsoft MVP "Cloud and Datacenter Management". Mon obsession depuis près de 15 ans ? Rendre l'administration système et la cybersécurité accessibles, que vous soyez junior ou confirmé. Plus qu'un métier, l'IT est pour moi une véritable passion. J’accompagne au quotidien les sysadmins et les professionnels de l’IT dans leur montée en compétences et leur veille technique.