CVE-2026-98432 : la suite, noyaux corrigés et mitigations à appliquer

Le 29 octobre, nous publiions notre première alerte sur CVE-2026-98432, la faille TCP du noyau Linux. Depuis, l'analyse technique d'Akamai a précisé le mécanisme, les versions corrigées et les mitigations possibles. Voici ce qu'il faut retenir et appliquer sur votre serveur, qu'il s'agisse d'un VPS Linux ou d'un serveur dédié.

Rappel : un use-after-free dans la poignée de main TCP

Un use-after-free est une lecture de mémoire déjà libérée. Ici, le noyau libère les options IPv4 attachées à une connexion entrante pendant qu'un autre processeur peut encore les lire. Selon l'analyse d'Akamai, la faille existe depuis Linux 4.4 et se déclenche avec un paquet SYN portant des options IPv4, suivi d'une retransmission. Aucun identifiant ni action de l'utilisateur n'est nécessaire.

Le score CVSS 3.1 est de 9.8 (critique). Le correctif a été validé en amont le 5 octobre 2026 et la CVE publiée le 15 octobre par l'équipe noyau, d'après Akamai. Une course critique perdue fait simplement échouer la poignée de main : un attaquant peut donc réessayer.

Les notions à connaître : noyau, pile TCP, sysctl

Quelques termes reviennent dans cette alerte. Un rappel rapide aide à comprendre pourquoi le correctif concerne tous les services réseau.

• Noyau Linux : cœur du système d'exploitation. Il gère la mémoire (la RAM), les processus et le réseau.
• Pile TCP/IP : partie du noyau qui ouvre et ferme les connexions réseau, y compris la poignée de main en trois temps (SYN, SYN-ACK, ACK).
• sysctl : outil qui lit et modifie les paramètres du noyau pendant son fonctionnement.
• Adresse IP et DNS : une connexion entrante arrive sur l'adresse IP de votre serveur. Le DNS traduit le nom de domaine en cette adresse IP.
• sudo : mécanisme qui permet à un compte standard d'exécuter une commande avec les droits administrateur.

Tout service qui accepte des connexions TCP entrantes passe par cette pile : un serveur web Apache qui héberge vos sites web (ou un CMS), une base de données MySQL ou PostgreSQL, un serveur SMTP pour vos emails, un accès FTP ou une application Python ou PHP exposée sur le réseau. La vérification du noyau concerne donc tout le serveur, pas une seule application.

Noyaux corrigés

Le correctif remplace un kfree() par un kfree_rcu(), afin que les options ne soient libérées qu'après une période de grâce RCU. Il figure dans :

Les distributions rétroportent souvent le correctif sans changer le numéro de version : pour un noyau de distribution, fiez-vous à l'avis de sécurité de l'éditeur, pas seulement à uname -r. D'après Akamai, au 30 octobre, Debian, SUSE, Oracle Linux et Amazon Linux 2023 proposaient des noyaux corrigés pour certaines versions, tandis qu'Ubuntu et RHEL n'en avaient pas encore. Cette situation a pu évoluer : vérifiez l'état actuel chez votre éditeur (par exemple la fiche Red Hat et son bulletin RHSB-2026-016). Si vous suivez la branche principale, notre article sur le noyau Linux 7.3 détaille la migration.

Où en est l'exploitation ?

Anthropic a indiqué disposer d'un exploit d'exécution à distance avec accès root, qui contourne le KASLR, mais ne l'a pas publié. Cet exploit s'appuie sur un listener MPTCP. Akamai ne connaît pas d'exploit public fonctionnel. Le défaut, lui, n'est pas propre à MPTCP : un listener TCP classique reste exposé à la course critique. Selon Akamai, le runtime Go active MPTCP par défaut sur les listeners Linux depuis Go 1.24, ce qui peut exposer des services sans que vous l'ayez choisi.

Mitigations en attendant le noyau corrigé

Elles ne remplacent pas la mise à jour. Les deux réglages cités par Akamai :

sysctl -w net.mptcp.enabled=0
sysctl -w net.ipv4.tcp_migrate_req=0

Pour les conserver après redémarrage, placez-les dans un fichier de /etc/sysctl.d/. Le second réglage concerne la migration des requêtes entre sockets, qui ouvre un second chemin vers la même erreur. Précision importante : couper MPTCP seul n'empêche pas l'exploitation, cela réduit seulement la probabilité de déclencher la course.

Pour repérer les listeners MPTCP :

ss -M -l -n -p -e

Notre guide pour lister les ports en écoute avec ss vous aide à lire cette sortie. Filtrer les paquets contenant des options IPv4 est une piste, mais Akamai prévient que cela peut casser des applications qui en dépendent : testez avant de déployer.

Plan d'action pour votre serveur

1. Relevez votre noyau avec uname -r et l'avis de votre distribution.
2. Faites une sauvegarde (backup) de vos données avant la mise à jour, en prévoyant l'espace disque nécessaire (les sauvegardes sont proposées en option), installez le paquet du noyau corrigé (package) dès qu'il est publié, puis redémarrez et revérifiez la version avec uname -r.
3. En attendant, configurez les deux sysctl ci-dessus, listez vos listeners MPTCP et surveillez vos journaux.
4. Limitez l'exposition réseau avec un firewall, c'est-à-dire un pare-feu nftables : n'ouvrez que les ports utiles. Moins de services joignables depuis l'extérieur, c'est moins de surface d'attaque.
5. Activez les mises à jour de sécurité automatiques si vous êtes sur Ubuntu, pour ne pas rater le prochain correctif.

Hébergement mutualisé, VPS, serveur dédié : qui gère le noyau ?

La réponse dépend du type d'hébergement. Un hébergement mutualisé (serveur mutualisé) partage un même serveur entre plusieurs sites hébergés, avec des droits limités : vous n'avez en général pas la main sur le noyau. Un VPS (serveur privé virtuel, ou serveur virtuel) est une machine virtuelle créée par la virtualisation, via un hyperviseur (VMware, KVM…) qui partage le matériel physique ; vous recevez des ressources allouées (vCPU, RAM, stockage) et un accès root. Un serveur dédié (serveur physique, hébergement dédié) est une machine physique entière, administrée par vous. Chez ElypseCloud, les VPS Linux sont sur SSD.

Un panneau de contrôle (ou panneau d'administration) comme Plesk ou Pterodactyl remplace la ligne de commande pour certaines tâches, mais le noyau reste à la charge de celui qui administre la machine. Sur une distribution comme Debian, Ubuntu, CentOS ou RHEL, vérifiez toujours l'avis de sécurité de l'éditeur.

Virtualisation : serveur virtuel ou serveur physique

La virtualisation consiste à découper une machine physique en plusieurs machines virtuelles, chacune avec son propre système. Un serveur virtuel tourne sur un hyperviseur, qui répartit le processeur, la mémoire et le stockage entre les machines. Un serveur physique, c'est-à-dire un serveur dédié, n'est pas partagé : il vous est réservé, matériel compris.

L'hébergement virtuel et le serveur privé virtuel désignent la même idée : une partie isolée d'un serveur physique, qui se comporte comme un serveur indépendant pour ses administrateurs. Chaque machine virtuelle a son propre noyau : sur votre VPS, c'est ce noyau qu'il faut corriger, comme sur un serveur dédié. Sur un VPS Linux comme sur un serveur dédié, c'est donc à vous d'appliquer le correctif.

VPS, serveur dédié ou serveur de jeu

Sur un VPS Linux ou un serveur dédié, vous administrez le système : le noyau, les sysctl et le redémarrage vous incombent. Les serveurs de jeu se gèrent depuis le panel Pterodactyl, sans accès SSH root : vous ne pouvez pas y modifier le noyau. Pour prendre en charge vous-même ce type de correctif, il faut un accès root. Pour durcir une machine fraîchement installée, consultez nos premiers réglages de sécurité.

Pour finir : la mise à jour du noyau reste la seule vraie réponse. Les mitigations réduisent le risque, elles ne le suppriment pas.