Une faille d'utilisation après libération (UAF) dans le code du noyau Linux qui établit les connexions TCP IPv4 entrantes, CVE-2026-98432, a été publiée par l'équipe CVE du noyau le 15 octobre avec un score CVSS 3.1 de 9,8 (critique) : accessible par le réseau, sans privilèges ni interaction de l'utilisateur. Le 27 octobre, Anthropic, dont un chercheur l'a signalée, a décrit un exploit : envoyer des paquets à des serveurs Linux disposant d'un écouteur TCP multichemin (MPTCP) permet à un attaquant d'exécuter des commandes arbitraires en tant que root. Dans leur preuve de concept, il a fallu 48 minutes pour faire fuiter à distance un pointeur du noyau, puis cinq minutes de plus pour atteindre l'exécution de commandes ; une course perdue ne fait qu'échouer la poignée de main concernée sans planter le système, si bien qu'un attaquant peut réessayer indéfiniment.

Qui est concerné

  • Le bogue se trouve dans le code TCP IPv4 ordinaire : un SYN portant des options IPv4 envoyé à un port TCP IPv4 en écoute l'atteint, et il remonte à Linux 4.4. Les connexions IPv6 ne sont pas touchées par le problème principal. AlmaLinux estime que tout système acceptant des connexions TCP IPv4 depuis des réseaux non fiables doit être considéré comme exposé.
  • L'exploit public nécessite un écouteur MPTCP. L'équipe de sécurité de Go a averti le 29 octobre que depuis Go 1.24, les programmes Go activent MPTCP par défaut pour les sockets d'écoute sous Linux, et bon nombre de panneaux d'administration, de proxys et d'outils de supervision sont écrits en Go ; l'équipe Go a aussi souligné que le bogue sous-jacent n'est pas propre à MPTCP et que des systèmes sans écouteur MPTCP pourraient être vulnérables à des attaques similaires.
  • État des correctifs : Debian 13 est corrigé à partir de 6.12.113-1 (DSA-6568-1) et Debian 12 à partir de 6.1.190-1 (DLA-4841-1) ; Red Hat a publié des correctifs du noyau pour RHEL 8, 9 et 10 le 1er novembre, et les dépôts de production d'AlmaLinux proposent des noyaux corrigés depuis le 2 novembre. Au 5 novembre, Ubuntu indiquait encore les noyaux génériques et cloud (comme linux-aws) de 22.04, 24.04 et 26.04 comme « Vulnerable, work in progress », les correctifs devant arriver respectivement dans 5.15.0-203.213, 6.8.0-149.149 et 7.0.0-43.43.

Que faire en attendant le correctif

  • Vérifiez d'abord MPTCP : sysctl net.mptcp.enabled indique s'il est actif, et sudo ss -lnMp liste les écouteurs MPTCP et leurs processus. Si vous n'avez pas besoin de MPTCP, désactivez-le : echo 'net.mptcp.enabled = 0' | sudo tee /etc/sysctl.d/90-disable-mptcp.conf, puis sudo sysctl -w net.mptcp.enabled=0. Comme le précise AlmaLinux, cela n'empêche que la création de nouveaux sockets MPTCP : redémarrez donc les services qui possèdent des écouteurs existants. Les programmes Go peuvent aussi être lancés avec GODEBUG=multipathtcp=0, même si l'équipe Go elle-même qualifie la désactivation programme par programme de parade fragile. La version v2.4.2 de 1Panel, publiée le 30 octobre, désactive désormais MPTCP par défaut.
  • Rejetez les paquets TCP portant des options IPv4 : le trafic normal ne les utilise presque jamais, et le cœur de la règle nftables publiée par AlmaLinux est meta l4proto tcp ip hdrlength > 5 counter drop (sur un crochet prerouting). Elle ne survit pas à un redémarrage, le trafic entre conteneurs d'un même hôte peut la contourner, et les réseaux qui s'appuient sur les étiquettes de sécurité CIPSO ne doivent pas l'utiliser.
  • Rien de tout cela n'est un correctif. Installez le paquet noyau de votre distribution dès qu'il paraît, redémarrez et vérifiez avec uname -r.

Ne confondez pas les deux failles du noyau

Ce lot couvre une autre faille du noyau : Fragnesia (CVE-2026-46300), dont la CISA a confirmé l'exploitation et l'enchaînement avec les failles PHP pour obtenir root. C'est une élévation de privilèges locale, avec des noyaux corrigés disponibles depuis mai, décrite dans cet article ; CVE-2026-98432, en revanche, peut être attaquée directement depuis le réseau, et les utilisateurs d'Ubuntu ne peuvent pour l'instant qu'atténuer le risque. Pour la configuration de base du pare-feu, voir le pare-feu ufw et la connexion par clé SSH ; pour la série de failles du noyau de septembre, voir ici ; et en cas de soupçon de compromission, suivez l'enquête et la re-sécurisation d'un VPS compromis.