Le 30 octobre 2026, Red Hat a publié une mesure de filtrage pour réduire l’exposition à CVE-2026-98432, une faille du noyau Linux. Elle vise RHEL 8, 9 et 10 ainsi que Red Hat OpenShift Container Platform, mais ne remplace pas l’installation d’un noyau corrigé. Au 1er novembre, la fiche CVE de Red Hat classait la faille « Critical » avec un score CVSS 3.1 de 9,8 (bulletin de sécurité ; fiche CVE).
Ce que réduit la règle nftables de Red Hat
CVE-2026-98432 est une vulnérabilité de type use-after-free, ou utilisation d’une zone mémoire après sa libération, dans le traitement IPv4/TCP du noyau Linux. Red Hat décrit une condition de concurrence qui peut survenir lors du traitement simultané de demandes TCP retransmises ou d’une migration de socket. Un attaquant distant n’a besoin ni de privilèges ni d’une interaction de l’utilisateur, mais doit viser un timing précis. Red Hat évoque des plantages, une corruption de mémoire et une possible exécution de code à distance.
La règle nftables publiée par Red Hat bloque les paquets IPv4/TCP entrants qui contiennent des options IP. L’entreprise indique que ce filtrage réduit l’exposition, mais ne peut pas empêcher entièrement l’exploitation et peut perturber des charges de travail. Red Hat présente l’installation d’un noyau corrigé comme la solution complète, et non cette règle de filtrage.
Amazon Linux indique ses familles de noyaux comme corrigées
La fiche officielle d’Amazon Linux, modifiée le 30 octobre, marque comme « Fixed » les familles de paquets concernées pour Amazon Linux 2 et Amazon Linux 2023. Pour Amazon Linux 2, cela comprend le noyau principal et les versions Extras 5.4, 5.10 et 5.15. Pour Amazon Linux 2023, la liste comprend les familles default, kernel6.12 et kernel6.18. La fiche attribue à la faille le niveau « Important » et un score CVSS 3.1 de 8,1 (suivi CVE d’Amazon Linux).
MPTCP concerne la démonstration, pas toute la faille
Le 27 octobre, Anthropic a rapporté que Claude avait produit une preuve de concept permettant d’exécuter des commandes avec les privilèges root sur un serveur Linux doté d’un socket d’écoute MPTCP. Dans cet essai, Anthropic a indiqué qu’il avait fallu 48 minutes pour obtenir un pointeur du noyau, puis cinq minutes supplémentaires pour parvenir à l’exécution d’une commande shell (compte rendu d’Anthropic).
Cette démonstration ne définit pas à elle seule le périmètre de la vulnérabilité. Le Go Security Team a précisé que le défaut du noyau n’était pas propre à MPTCP et que des attaques similaires pouvaient être possibles sans socket d’écoute MPTCP. NeoTeo avait déjà présenté les cinq chaînes d’exploitation décrites par Anthropic. Le Go Security Team indique aussi que Go 1.24 active MPTCP par défaut pour les sockets d’écoute sous Linux et juge fragile sa désactivation au cas par cas ; son conseil est d’installer un noyau corrigé (recommandations de l’équipe de sécurité Go).
Ce que Sophos et OpenVPN disent de leurs produits
Le 30 octobre, Sophos a confirmé que Sophos Firewall était affecté. L’entreprise a précisé que MPTCP n’y était pas activé et que cela pouvait réduire le risque ; ses équipes évaluaient des correctifs du noyau amont pour une future version de SFOS (réponse de l’assistance Sophos).
OpenVPN indique que les services standard d’Access Server, notamment son interface web, ses démons et SSH, utilisent TCP à chemin unique plutôt que des sockets d’écoute MPTCP. L’entreprise recommande néanmoins d’installer le noyau corrigé fourni par la distribution et de redémarrer l’hôte, car celui-ci peut rester vulnérable (consignes d’OpenVPN pour Access Server).
