Faille TCP Linux CVE-2026-98432 : protéger vos serveurs

Qu’est-ce que CVE-2026-98432 ?

CVE-2026-98432 est une vulnérabilité du noyau Linux, le cœur des systèmes d’exploitation Linux. Son intitulé officiel est ipv4: free inet_opt and ireq_opt after an RCU grace period ^[1]. L’équipe CVE du noyau Linux l’a attribuée et a publié la fiche le 15 octobre 2026 ^[1]. La fiche lui donne un score de base CVSS 3.1 de 9.8, soit le niveau critique ^[1].

La faille est un use-after-free : un programme continue d’utiliser une zone mémoire après l’avoir libérée, alors que cette mémoire peut déjà contenir d’autres données. Elle se trouve ici dans le code qui traite les demandes de connexion TCP IPv4 entrantes ^[10]. Le vecteur CVSS est AV:N/AC:L/PR:N/UI:N. Autrement dit, l’attaque passe par le réseau, présente une faible complexité et ne requiert ni privilège ni interaction de l’utilisateur ^[1].

Le bug existe depuis Linux 4.4, où il est apparu avec le commit 079096f103fa ^[2]. Un correctif écrit par Eric Dumazet a été intégré le 5 octobre 2026 et figure désormais dans le noyau principal (mainline) ^[3]. Il a été rétroporté dans les branches stables maintenues ^[2][4].

Quels systèmes sont concernés ?

Selon Red Hat, la faille touche tout système exécutant un noyau vulnérable avec la pile réseau TCP IPv4 activée. Les systèmes qui acceptent des connexions TCP entrantes sont les plus directement exposés ^[6]. AlmaLinux recommande de considérer comme exposé tout système acceptant des connexions TCP IPv4 depuis des réseaux non fiables ^[10]. IPv6 n’est pas concerné par le problème principal ^[2].

Comment fonctionne la vulnérabilité ?

Une connexion TCP commence par une poignée de main. Le client envoie un paquet SYN, le serveur répond par un SYN-ACK et le client confirme. Un SYN peut transporter des options IPv4, des champs supplémentaires facultatifs de l’en-tête IP. Record Route et Timestamp en sont deux exemples ^[1].

D’après la description du noyau, la fonction tcp_v4_syn_recv_sock() transmet les options enregistrées au nouveau socket enfant sans les copier ^[2]. Pendant ce temps, un autre cœur du processeur peut traiter un SYN retransmis pour la même demande et construire un SYN-ACK qui lit ces options ^[2]. Rien n’empêche le socket enfant d’être libéré alors que le SYN-ACK est encore en cours de construction. Ses options sont libérées par un simple kfree(), si bien que le noyau lit de la mémoire libérée dans ip_options_build() ^[2].

Une seconde situation de concurrence, similaire, existe lorsque la migration des sockets de requête est activée, soit via net.ipv4.tcp_migrate_req=1, soit via un programme BPF reuseport ^[2]. Le correctif oblige les deux chemins de libération à attendre une période de grâce RCU, en utilisant kfree_rcu() dans inet_sock_destruct() et tcp_v4_reqsk_destructor() ^[2]. RCU (read-copy-update) est une technique du noyau qui retarde la libération de la mémoire jusqu’à ce qu’aucun lecteur ne puisse encore l’utiliser.

Que pourrait en faire un attaquant ?

Les notes d’évaluation de la fiche CVE décrivent trois conséquences ^[1] :

• Divulgation d’informations : la mémoire libérée peut être réutilisée par d’autres données, et son contenu peut être copié dans le SYN-ACK renvoyé à l’attaquant ^[1].
• Corruption de la mémoire : des longueurs et des décalages périmés peuvent orienter des écritures du noyau hors des limites, avec une possible corruption du flot de contrôle ^[1].
• Plantages : une valeur de longueur réutilisée peut déclencher une panique du noyau, et les écritures parasites peuvent elles aussi faire planter le noyau ^[1].

Red Hat ajoute qu’exécuter du code de manière fiable grâce à ce bug très dépendant du minutage exige un contrôle précis du tas. L’éditeur le classe néanmoins critique, car il n’exige aucun prérequis réseau et peut provoquer une grave instabilité ^[7].

Qu’a révélé Anthropic, et quel rôle joue MPTCP ?

Le 27 octobre 2026, la Frontier Red Team d’Anthropic a publié un compte rendu des vulnérabilités qu’elle a découvertes à l’aide des modèles Claude ^[4][11]. Pour CVE-2026-98432, l’équipe indique avoir mis au point un exploit qui permet à un attaquant distant d’exécuter des commandes arbitraires en root sur des serveurs Linux dotés d’un socket d’écoute Multipath TCP (MPTCP), sans identifiants ni interaction de l’utilisateur ^[4]. MPTCP est une extension de TCP qui permet à une même connexion d’emprunter plusieurs chemins réseau à la fois.

Anthropic décrit deux étapes. D’abord, l’exploit divulgue un pointeur du noyau pour contourner KASLR, la randomisation des adresses du noyau. Ensuite, il écrase un pointeur de rappel afin que le noyau exécute en root une commande choisie par l’attaquant ^[4]. Une course perdue ne fait qu’échouer la poignée de main, sans faire planter le système, si bien qu’un attaquant peut réessayer indéfiniment ^[4]. Dans la preuve de concept d’Anthropic, la fuite d’un pointeur du noyau a pris 48 minutes, et l’exécution de commandes 5 minutes de plus ^[4].

MPTCP est-il nécessaire ?

Non, selon les éditeurs qui l’ont évaluée. Red Hat affirme que MPTCP n’est pas une condition nécessaire de cette faille et que les systèmes où MPTCP est désactivé restent concernés ^[6]. L’équipe de sécurité de Go indique que l’exploit présenté nécessite un socket d’écoute MPTCP, mais que le bug sous-jacent n’est pas propre à MPTCP ^[5]. Go est concerné ici parce que les programmes Go activent MPTCP par défaut pour les sockets d’écoute sous Linux depuis Go 1.24 ^[5].

D’après Akamai, Anthropic n’a pas publié son exploit root, et le 2 novembre 2026 Akamai déclarait n’avoir connaissance d’aucun exploit public fonctionnel ^[11].

Quelles versions du noyau et quelles distributions sont corrigées ?

L’équipe CVE du noyau recense ces correctifs en amont : 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 et la mainline 7.3 ^[2]. La plupart des utilisateurs exécutent toutefois un noyau compilé par leur distribution, qui suit sa propre numérotation. Consultez l’avis de votre distribution plutôt que de comparer les numéros amont.

Situation au 3 novembre 2026 :

• Red Hat Enterprise Linux : des noyaux corrigés ont été publiés le 1 novembre 2026 pour RHEL 8, 9 et 10. RHEL 6 et 7 sont indiqués comme non concernés. Le noyau temps réel de RHEL 9 et les images de nœuds OpenShift figurent encore parmi les produits concernés ^[7].
• Ubuntu : Ubuntu classe le problème comme critique. Son outil de suivi indique que les versions 26.10, 26.04 LTS, 24.04 LTS et 22.04 LTS sont vulnérables, avec des correctifs en préparation ; les versions 20.04, 18.04 et 16.04 sont également listées comme vulnérables, et la 14.04 comme non concernée ^[8].
• Debian : des correctifs sont disponibles pour Debian 12 bookworm (linux 6.1.190-1 et linux-6.12 6.12.113-1~deb12u1) et Debian 13 trixie (linux 6.12.113-1), ainsi que pour unstable ^[9].
• AlmaLinux : des noyaux corrigés pour AlmaLinux 8, 9 et 10 se trouvent dans les dépôts de production ^[10].
• Autres : Akamai a signalé que SUSE, Oracle Linux et Amazon Linux 2023 avaient publié des noyaux corrigés pour certaines versions au 30 octobre 2026 ^[11].

Qu’en est-il des téléphones Android ?

Android repose sur le noyau Linux, mais le bulletin de sécurité Android publié le 2 novembre 2026 ne mentionne pas CVE-2026-98432 ^[13]. Les propriétaires de téléphones doivent installer les mises à jour de sécurité au fur et à mesure que leur fabricant les publie.

Comment vérifier si un serveur est vulnérable ?

1. Identifiez le noyau en cours d’exécution. Lancez uname -r. Un correctif ne compte qu’une fois la machine redémarrée sur le nouveau noyau. AlmaLinux demande aux utilisateurs de redémarrer et de vérifier la version avec uname -r ^[10].
2. Comparez avec l’outil de suivi de votre éditeur. Recherchez CVE-2026-98432 sur la page de sécurité de votre distribution. Red Hat ^[7], Ubuntu ^[8], Debian ^[9] et AlmaLinux ^[10] indiquent chacun les versions de paquets qui contiennent le correctif.
3. Vérifiez MPTCP. sysctl net.mptcp.enabled indique si MPTCP est activé. sudo ss -lnMp liste les sockets d’écoute MPTCP et les processus qui les détiennent ^[10]. Akamai suggère aussi de vérifier net.ipv4.tcp_migrate_req ^[11].
4. Repérez les services Go. Les programmes compilés avec Go 1.24 ou une version ultérieure ouvrent par défaut des sockets d’écoute MPTCP sous Linux ^[5]. Tout service Go que vous exploitez peut donc exposer le chemin exploité par Anthropic.
5. Vérifiez les produits dérivés. Red Hat prévient que tout produit reposant sur le noyau RHEL, notamment OpenShift, OpenStack et Red Hat Virtualization, peut également être concerné ^[6].

Comment corriger ou atténuer CVE-2026-98432 ?

La véritable correction est un noyau corrigé. Red Hat qualifie l’application des mises à jour du noyau de seule solution complète ^[6], et l’équipe de sécurité de Go estime que la meilleure correction consiste à passer à un noyau corrigé ^[5]. Installez la mise à jour du noyau de votre distribution, redémarrez et vérifiez la version en cours d’exécution.

Que faire en attendant un correctif ?

• Rejetez les paquets TCP porteurs d’options IPv4. Red Hat publie, et l’outil de suivi d’Ubuntu répertorie comme contournement proposé par des utilisateurs, une règle nftables qui rejette les paquets TCP IPv4 entrants dont l’en-tête IP dépasse les 20 octets de base, c’est-à-dire les paquets porteurs d’options (ip hdrlength > 5) ^[6][8]. Les options TCP habituelles, comme les horodatages et la mise à l’échelle de la fenêtre, se trouvent dans l’en-tête TCP et ne sont pas touchées ^[8]. Les deux éditeurs précisent que la règle réduit le risque mais ne peut pas empêcher totalement l’exploitation ^[6][8].
• Connaissez les limites de la règle. AlmaLinux signale que sa version ne survit pas à un redémarrage, que le trafic entre conteneurs d’un même hôte peut la contourner, qu’elle rejette aussi les paquets transférés sur les hôtes de routage et qu’elle perturbe les réseaux qui s’appuient sur les étiquettes CIPSO/NetLabel ^[10]. Ubuntu note que les conteneurs dotés d’une pile réseau distincte nécessitent d’appliquer la règle séparément ^[8].
• Désactivez MPTCP si vous n’en avez pas besoin. Le paramètre net.mptcp.enabled=0 désactive MPTCP pour tout le système ^[10]. Akamai suggère aussi de définir net.ipv4.tcp_migrate_req=0 ^[11]. Akamai prévient que désactiver MPTCP ne suffit pas à empêcher l’exploitation ; cela réduit seulement la probabilité de déclencher la situation de concurrence ^[11]. Les programmes Go peuvent aussi s’en exclure avec GODEBUG=multipathtcp=0, mais l’équipe Go juge fragiles ces exclusions programme par programme ^[5].
• Filtrez en périphérie. Pour OpenShift, Red Hat note que les règles appliquées sur un nœud ne filtrent pas le trafic entre pods, alors qu’un filtrage à la frontière du réseau, en amont du cluster, évite cette limite ^[6].

L’option init_on_free=1 est-elle utile ?

Un message publié sur oss-security a suggéré l’option de démarrage init_on_free=1 comme mesure provisoire supplémentaire. Un membre de l’équipe noyau de CIQ a répondu qu’elle n’atténue pas réellement cette CVE et ne devrait pas peser dans les avis de sécurité ^[12]. Considérez-la comme un durcissement général, et non comme une atténuation de ce bug.

CVE-2026-98432 est-elle exploitée ?

Au 3 novembre 2026, CVE-2026-98432 ne figure pas dans le catalogue Known Exploited Vulnerabilities de la CISA, la liste du gouvernement américain des failles dont l’exploitation réelle est confirmée ^[14]. Akamai a déclaré le 2 novembre 2026 n’avoir connaissance d’aucun exploit public fonctionnel ^[11]. Cela ne prouve pas que personne n’exploite le bug. L’existence d’un exploit fiable a été démontrée ^[4], et les détails techniques sont publics dans le correctif du noyau ^[3].

L’évaluation de la gravité a également évolué au fil du temps. La CVE a d’abord été publiée le 15 octobre 2026 ^[1]. Elle a attiré davantage l’attention après le compte rendu d’Anthropic du 27 octobre ^[4][11]. Les bulletins des éditeurs, accompagnés de mesures d’atténuation provisoires, ont suivi entre le 29 octobre et le 2 novembre ^[5][6][10]. Les administrateurs qui n’ont fait que survoler la fiche initiale ont pu passer à côté des recommandations ultérieures.

Et ensuite ?

Red Hat indique que son enquête se poursuit et que son bulletin sera mis à jour à mesure que de nouvelles informations apparaîtront ^[6]. Les paquets restants, comme le noyau temps réel de RHEL 9 et les images OpenShift ^[7] ou les noyaux Ubuntu encore en préparation ^[8], devraient recevoir des correctifs dans les jours ou les semaines à venir. Consultez les outils de suivi des éditeurs plutôt que les résumés de presse, car ces pages ont changé plusieurs fois au cours des premières semaines.

Le correctif du noyau laisse par ailleurs un problème connexe en suspens. La description du noyau indique que la fonction IPv6 tcp_v6_reqsk_destructor() présente le même problème de migration avec des options définies uniquement par CALIPSO, et que celui-ci sera traité dans un correctif distinct ^[2]. Selon sa politique de divulgation coordonnée, Anthropic accorde 90 jours pour le correctif, plus 45 jours supplémentaires avant d’aborder des détails allant au-delà de l’avis public ^[4]. D’autres détails techniques pourraient donc être publiés plus tard.

Ces informations techniques sont d’ordre général et ne remplacent ni l’avis de sécurité de votre éditeur ni la procédure de réponse aux incidents de votre organisation.