Faille TCP du noyau Linux : le correctif n’agit qu’après un redémarrage

Le noyau Linux fait tourner la quasi-totalité des serveurs qui hébergent des sites et des boutiques en ligne. Une faille dans sa gestion des connexions TCP, publiée à la mi-octobre, a été réévaluée début novembre au niveau le plus grave. Les correctifs existent, mais ils ne servent à rien tant que le serveur n’a pas redémarré.

Ce qui s’est passé

La faille, référencée CVE-2026-98432, a été corrigée dans le noyau Linux et rendue publique le 15 octobre. Elle se trouve dans le code qui accepte les nouvelles connexions TCP en IPv4 : en envoyant des paquets construits d’une certaine façon, une personne extérieure peut amener le noyau à réutiliser une zone de mémoire déjà libérée. Il lui faut gagner une « course » de quelques microsecondes, mais un essai raté ne laisse pas de trace visible et peut être répété.

Les éditeurs de distributions l’ont d’abord classée comme un risque de plantage du serveur : Red Hat la notait 5,9 sur 10 le 17 octobre. Le 27 octobre, l’équipe de sécurité d’Anthropic a annoncé qu’un de ses modèles d’IA de recherche avait obtenu, en moins d’une heure, un accès administrateur complet à un serveur de test à partir de cette seule faille. Le code de cette démonstration n’a pas été publié et n’a pas été reproduit de façon indépendante, mais Red Hat est passé à 9,8 sur 10 le 1^er novembre, la note que lui donnaient déjà les développeurs du noyau ; Ubuntu retient la même.

Faut-il s’inquiéter ?

Il faut agir cette semaine, sans panique. Au 5 novembre, aucune attaque réussie n’avait été recensée, et la démonstration d’Anthropic visait une configuration particulière (un service qui accepte le TCP multichemin, MPTCP). Plusieurs équipes estiment pourtant que la faille est exploitable sans cette condition, et des balayages d’Internet à la recherche de serveurs MPTCP ont été observés dès le 2 novembre. Comme pour PHP2Shell en octobre, l’intelligence artificielle raccourcit le temps entre la publication d’une faille et une attaque qui fonctionne.

La faille vise le serveur, pas le site : PrestaShop, WordPress, WooCommerce ou un site sur mesure sont concernés de la même façon dès qu’ils tournent sur Linux.

Comment savoir si votre serveur est concerné

• Hébergement mutualisé : vous n’avez pas la main sur le noyau. Demandez à votre hébergeur si ses serveurs ont été redémarrés sur un noyau corrigé contre CVE-2026-98432.
• Serveur dédié ou VPS : la commande uname -r donne la version du noyau en cours d’exécution. C’est elle qui compte, pas celle du dernier paquet installé.

Versions corrigées, par branche du noyau : 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56 et 7.2.10. Pour les distributions courantes :

• Debian 13 « Trixie » : noyau 6.12.113-1 ou plus récent (DSA-6568-1) ;
• Debian 12 « Bookworm » : noyau 6.1.190-1 ou plus récent (DLA-4841-1) ;
• Red Hat Enterprise Linux 8, 9 et 10 et leurs dérivés (AlmaLinux, Rocky Linux) : noyaux publiés le 1^er novembre ;
• Ubuntu 22.04, 24.04 et 26.04 : au 4 novembre, les noyaux corrigés n’étaient disponibles qu’en test (dépôt « proposed ») ; Ubuntu 20.04 et plus ancien n’ont pas de correctif annoncé.

Les distributions gardent leur propre numérotation : sur Debian ou Red Hat, le journal des modifications du paquet du noyau dit si le correctif est présent.

Ce qu’il faut faire

1. Installer le noyau corrigé de la distribution, puis redémarrer le serveur sur ce noyau, à une heure creuse : quelques minutes d’interruption pour une boutique.
2. Vérifier après le redémarrage, avec uname -r, que c’est bien le nouveau noyau qui tourne.
3. Si le correctif n’est pas encore disponible, comme sur Ubuntu au début du mois, l’administrateur du serveur peut filtrer au pare-feu les paquets qui servent à déclencher la faille (en-tête IPv4 avec options), une mesure recommandée par plusieurs distributions. Elle se teste avant d’être généralisée et ne remplace pas la mise à jour.

W4U Audit ne lit pas la version du noyau : le module voit PrestaShop, PHP et la configuration exposée, pas le système qui les fait tourner. La vérification se fait sur le serveur, ou auprès de l’hébergeur. Sur les serveurs que j’administre, la mise à jour et le redémarrage font partie de la maintenance.