Ubuntu et Red Hat corrigent à leur tour une faille critique du cœur de Linux

Il aura fallu 53 minutes. C'est le temps qu'aurait mis, selon Anthropic, un modèle d'IA interne et non publié pour écrire une attaque capable d'obtenir les droits root, à distance et sans mot de passe, sur un serveur Linux. L'entreprise l'a affirmé le 27 octobre. La faille visée porte le numéro CVE-2026-98432. Au 30 octobre, Ubuntu et Red Hat, deux des distributions les plus répandues en entreprise, n'avaient encore publié aucun noyau corrigé.

Le bug est un use-after-free : le noyau relit une zone de mémoire qu'il vient de libérer. Il se trouve dans le code qui gère l'ouverture des connexions TCP en IPv4. On le déclenche avec une demande de connexion qui porte des « options IP », un champ rarement utilisé de l'en-tête des paquets. Le défaut existe depuis Linux 4.4. Les développeurs du noyau l'ont corrigé le 5 octobre, puis ont publié la CVE le 15 octobre. Le 24 octobre, ils lui ont donné la note de 9,8 sur 10.

Une note qui divise les éditeurs

Tous ne partagent pas cette évaluation. Red Hat a d'abord classé la faille « modérée » (5,9), en considérant qu'elle servait surtout à faire planter une machine. Selon TuxCare, l'éditeur l'a relevée à 8,1 le 29 octobre, au niveau retenu par Oracle, SUSE et Amazon. Sa fiche affiche désormais 9,8 et classe la faille « critique », des valeurs qu'elle dit préliminaires. La démonstration d'Anthropic concerne un cas précis : un serveur qui accepte des connexions MPTCP (Multipath TCP), une extension de TCP qui utilise plusieurs chemins réseau à la fois. D'après BleepingComputer, personne n'a montré publiquement d'exécution de code sur un serveur sans MPTCP.

Ce cas est moins rare qu'il n'y paraît. Toujours selon BleepingComputer, les programmes écrits en Go à partir de la version 1.24 activent MPTCP par défaut quand le noyau le permet. Certains services peuvent donc l'utiliser à l'insu de leurs administrateurs. Anthropic n'a publié ni le code de l'attaque ni la configuration testée, et TuxCare indique qu'aucune reproduction indépendante n'était connue au 30 octobre. Aucune exploitation par des pirates n'a été signalée, et la faille ne figure pas au catalogue des failles exploitées de l'agence américaine CISA.

Qui a déjà un noyau corrigé ?

• Debian : corrigé dans les noyaux 6.1.190-1 (Debian 12) et 6.12.113-1 (Debian 13).
• SUSE, Oracle Linux (UEK), Amazon Linux : correctifs publiés pour une partie des versions.
• Ubuntu : 22.04, 24.04, 26.04 et 26.10 restent vulnérables, avec des correctifs « en cours ». Les versions 16.04, 18.04 et 20.04 sont listées comme vulnérables.
• Red Hat Enterprise Linux 8, 9 et 10, ainsi que Rocky Linux : touchés et pas encore corrigés. RHEL 7 n'est pas concerné. AlmaLinux propose des noyaux corrigés dans son dépôt de test.
• Côté noyau officiel, les versions 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 7.3.

Que faire en attendant ?

Désactiver MPTCP ne suffit pas : selon BleepingComputer, du trafic TCP ordinaire peut aussi déclencher le bug. AlmaLinux et TuxCare proposent de rejeter les paquets TCP entrants qui portent des options IP :

nft add table ip cve_2026_98432
nft add chain ip cve_2026_98432 prerouting '{ type filter hook prerouting priority -300; }'
nft add rule ip cve_2026_98432 prerouting meta l4proto tcp ip hdrlength != 5 drop

Cette règle disparaît au redémarrage. AlmaLinux précise que le trafic entre conteneurs d'une même machine peut lui échapper, et TuxCare dit ne pas l'avoir testée. Vérifiez aussi avec sysctl net.mptcp.enabled si MPTCP est actif. S'il ne sert à rien, désactivez-le et listez les services qui l'écoutent avec ss -lnMp. Limitez enfin l'accès aux serveurs exposés aux seules adresses de confiance.

Tout cela ne remplace pas le correctif : il faudra installer le nouveau noyau puis redémarrer. La question est maintenant de savoir quand Ubuntu et Red Hat le publieront.

Mise à jour du 13 novembre 2026

Les deux distributions ont en partie rattrapé leur retard sur CVE-2026-98432, la faille du noyau Linux notée 9,8 sur 10. Le 27 octobre, Anthropic, l'éditeur de Claude, a indiqué qu'un de ses modèles de recherche internes, non publié, avait écrit un exploit permettant à un attaquant distant, sans identifiants, d'exécuter des commandes sur des serveurs Linux dotés d'un service Multipath TCP (MPTCP). Red Hat a publié le 1er novembre un noyau corrigé pour RHEL 10 (avis RHSA-2026:93413, version 6.12.0-211.72.1.el10_2). Selon le site PBX Science, les avis RHSA-2026:93412 et RHSA-2026:93414, publiés le même jour, corrigent RHEL 9 (5.14.0-687.64.1.el9_8) et RHEL 8 (4.18.0-553.182.1.el8_10). Un avis du 3 novembre couvre aussi RHEL 8.4 en support étendu (RHSA-2026:94623). Au 2 novembre, toujours selon PBX Science, le noyau temps réel de RHEL 9, RHEL pour NVIDIA et les images RHEL CoreOS d'OpenShift étaient encore listés comme vulnérables.

Ubuntu indique sur sa fiche, mise à jour le 11 novembre, que le noyau principal est corrigé dans quatre de ses versions : 22.04 (5.15.0-203.213), 24.04 (6.8.0-149.149), 26.04 (7.0.0-43.43) et 26.10 (7.3.0-10.10). Les noyaux pour AWS, Azure, Google Cloud et Oracle le sont aussi. Les correctifs restent « en cours » pour 16.04, 18.04 et 20.04, ainsi que pour le noyau certifié FIPS générique et les noyaux HWE (plus récents, proposés en option) de 22.04 et 24.04. D'autres variantes, dont celle pour Raspberry Pi en 26.04 et certaines variantes NVIDIA, ne sont pas encore corrigées non plus.

Dans tous les cas, il faut redémarrer la machine pour que le noyau corrigé soit actif. Red Hat précise que la règle de pare-feu proposée en attendant réduit l'exposition sans l'empêcher entièrement, et qu'elle doit être retirée une fois la mise à jour installée.