Passer au contenu principal
Publié le 14 novembre 2026
CVE-2026-98432 — noyau Linux, établissement des connexions TCP IPv4. La faille est notée 9.8 par l’équipe sécurité du noyau. Elle est exploitable à distance, sans authentification, sur tout serveur qui accepte des connexions TCP en IPv4. Installez le noyau corrigé de votre distribution et redémarrez dès aujourd’hui.

Le problème en deux phrases

Pendant l’établissement d’une connexion TCP, le noyau transmet les options IP de la demande de connexion au socket créé, sans les copier, puis les libère sans attendre que les autres processeurs aient fini de les lire. Un SYN retransmis, traité au même moment sur un autre processeur, construit alors son SYN-ACK à partir d’une mémoire déjà libérée : c’est un use-after-free dans ip_options_build(). Un second chemin mène au même bug : la migration des demandes de connexion (net.ipv4.tcp_migrate_req=1 ou un programme BPF BPF_SK_REUSEPORT_SELECT_OR_MIGRATE). Versions touchées :
  • tous les noyaux Linux depuis la 4.4 ;
  • corrigés en amont dans 7.3-rc7, et dans les branches stables 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56 et 7.2.10.
Le score de 9.8 vient de l’équipe CVE du noyau et figure dans la fiche NVD. Red Hat retient le même score et classe la faille critique. Ubuntu lui donne la priorité critique.
Anthropic a décrit un exploit écrit par Claude, un modèle de recherche interne non publié : exécution de code à distance en root, sans clic, sur un serveur qui expose un listener Multipath TCP (MPTCP). La publication décrit l’exploit sans en fournir le code. La faille ne figure pas au catalogue KEV de la CISA (version du 13 novembre 2026).

Évaluer son exposition

La question à se poser : votre serveur accepte-t-il des connexions TCP en IPv4 ? C’est le cas de presque tous les serveurs : SSH, web, mail, base de données. MPTCP n’est pas une condition de la faille. L’exploit publié s’en sert, mais Red Hat rappelle que le bug est dans le TCP IPv4 ordinaire : RHEL, qui désactive MPTCP par défaut, reste vulnérable. Pour voir le noyau en cours d’exécution :
Désactiver MPTCP (sysctl -w net.mptcp.enabled=0) ne protège pas : cela ferme la configuration démontrée, pas la faille. De même, ss -Mlnp montre si un service écoute en MPTCP, mais un résultat vide ne veut pas dire que le serveur est hors de danger. L’équipe sécurité de Go fait la même mise en garde : depuis Go 1.24, les programmes Go ouvrent leurs sockets d’écoute en MPTCP par défaut sous Linux, et seule la mise à jour du noyau règle le problème.

Mettre à jour le noyau par distribution

Le correctif est la mise à jour du noyau, suivie d’un redémarrage. Tant que le serveur n’a pas redémarré, l’ancien noyau reste chargé et la faille reste ouverte. Avant de redémarrer un VPS en production, prenez un snapshot. Si le serveur ne revient pas sur le réseau, la console KVM donne accès à l’écran de démarrage.

Debian

Ubuntu

Les noyaux spécialisés (cloud, lowlatency, FIPS) ont leurs propres versions : consultez la page Ubuntu de la CVE.

RHEL, AlmaLinux, Rocky Linux

Les versions AlmaLinux sont celles de l’avis AlmaLinux. Pour Rocky Linux et les versions EUS de RHEL, consultez le bulletin Red Hat RHSB-2026-016 et l’avis de votre distribution.

Kubernetes

Chaque nœud doit recevoir le noyau corrigé et redémarrer. Videz les nœuds un par un pour garder le service :
Red Hat précise qu’une règle nftables posée sur un nœud ne filtre que le trafic qui traverse l’espace réseau de l’hôte, pas le trafic entre pods. Un filtrage en bordure, devant le cluster, n’a pas cette limite.

Mitigation en attendant le correctif

Red Hat et Ubuntu publient la même règle nftables : elle rejette les paquets TCP IPv4 entrants qui portent des options IP, ce qui supprime l’entrée dont la faille a besoin. Les options TCP habituelles (timestamps, window scaling) passent toujours, de même que l’IPv6. La règle s’applique sans redémarrer les services. Ses limites :
  • elle réduit le risque sans l’éliminer et ne remplace pas la mise à jour du noyau ;
  • elle coupe les connexions qui dépendent d’options IPv4 ;
  • elle couvre l’hôte ; un conteneur qui a son propre réseau doit recevoir la règle séparément, et le trafic entre conteneurs d’un même hôte peut la contourner ;
  • testez-la sur votre trafic avant de la déployer en production.

Debian et Ubuntu

Procédure publiée par Ubuntu. Elle suppose que le pare-feu est géré par /etc/nftables.conf, sans UFW ni firewalld ; Debian utilise le même fichier.

RHEL, AlmaLinux, Rocky Linux

Procédure publiée par Red Hat. Enregistrez la règle dans un fichier cve-2026-98432.nft :
Puis vérifiez et appliquez-la :
Cette règle ne survit pas au redémarrage. Pour la rendre persistante, suivez la section « Making the mitigation persistent » du bulletin RHSB-2026-016 : Red Hat avertit qu’activer nftables.service peut entrer en conflit avec firewalld ou une configuration existante.

Vérifier la mitigation

La commande doit afficher la table et sa chaîne input. Le compteur de la ligne drop indique combien de paquets ont été rejetés. Une erreur signifie que la règle n’est pas chargée.

Annuler la mitigation

Une fois le noyau corrigé chargé (vérifiez avec uname -r ou uname -v), retirez la règle.
Si vous avez rendu la règle persistante sur RHEL, suivez la section « Reverting After Patching » du bulletin Red Hat.

Et après ?

La règle nftables n’est qu’un palliatif : la cible reste le noyau corrigé, chargé après redémarrage. Pour une autre faille récente du noyau Linux, lisez Copy Fail (CVE-2026-31431). Pour toute question technique, ouvrez un ticket depuis votre espace client OnetSolutions.