Faille CVE-2026-98432 du noyau Linux : protéger son VPS ou son serveur dédié

Une faille du noyau Linux, CVE-2026-98432, permet en théorie de prendre la main sur un serveur à distance, sans mot de passe, en lui envoyant des paquets TCP bien choisis. Elle date de Linux 4.4 et touche donc la plupart des serveurs Linux en service. Le 27 octobre, Anthropic a annoncé l’avoir exploitée jusqu’aux droits root ; le 30, Red Hat, AlmaLinux et CloudLinux ont publié leurs avis, mais tous les noyaux corrigés ne sont pas encore livrés. État des correctifs relevé le 2 novembre 2026.

L’essentiel en six points

• La faille est dans le code TCP pour IPv4 du noyau, au moment où une connexion entrante s’établit. Il suffit qu’un port TCP soit joignable : un site web, SSH ou une messagerie en ouvrent tous.
• Les correctifs arrivent en ordre dispersé. Debian, Oracle Linux (noyau UEK) et plusieurs versions de SUSE sont corrigés ; Ubuntu et Red Hat Enterprise Linux ne le sont pas encore ; AlmaLinux propose ses noyaux en dépôt de test.
• MPTCP n’est qu’une porte d’entrée. La démonstration d’Anthropic visait un serveur qui écoute en Multipath TCP, mais le défaut est dans le TCP ordinaire : désactiver MPTCP ne dispense pas de corriger.
• Une règle de pare-feu fait patienter : Red Hat publie une règle nftables qui rejette les paquets TCP porteurs d’options IPv4, dont le trafic ordinaire n’a pas besoin. Elle réduit l’exposition, elle ne corrige rien.
• Un noyau installé n’est pas un noyau actif : il faut redémarrer, ou disposer d’un correctif à chaud, puis vérifier avec uname -r.
• Aucune exploitation réelle n’est connue au 2 novembre, et le code d’Anthropic n’a pas été publié. C’est une fenêtre pour corriger calmement, pas une raison d’attendre.

Ce qui se passe dans le noyau

Une connexion TCP commence par un échange en trois temps : le client envoie un paquet SYN, le serveur répond SYN-ACK, le client confirme. Entre la demande et la confirmation, le noyau garde une petite fiche de la connexion en cours, avec, le cas échéant, les options IP du paquet reçu. Ces options vivent dans l’en-tête IPv4 lui-même ; elles sont rarissimes sur Internet, et rien dans un site web ou une messagerie n’en a besoin.

Le défaut, décrit dans le communiqué de l’équipe CVE du noyau : quand la connexion est acceptée, la nouvelle socket reprend ces options sans en faire de copie, puis les libère dès qu’elle se ferme. Or un SYN retransmis par le client peut être traité au même moment sur un autre processeur, qui relit ces mêmes options pour construire un nouveau SYN-ACK. Il lit alors une mémoire déjà rendue : c’est un use-after-free, la famille de bogues qu’un attaquant patient transforme en écriture dans la mémoire du noyau. Un second chemin, plus rare, passe par la migration des demandes de connexion entre sockets (réglage net.ipv4.tcp_migrate_req=1 ou programme BPF dédié). IPv6 n’est pas touché par le premier chemin.

Le code fautif remonte à une modification de Linux 4.4, publié en janvier 2016. La correction tient en deux lignes : libérer la mémoire après un délai de grâce (kfree_rcu()) au lieu de tout de suite. Écrite par Eric Dumazet, datée du 1^er octobre et signalée par un chercheur d’Anthropic, elle est entrée dans Linux 7.3 (commit e3f33b0a1d89). Les branches suivies ont reçu leur version corrigée : 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56 et 7.2.10. La liste n’en compte aucune pour les branches antérieures à 5.10, qui ne sont plus suivies. La CVE a été publiée le 15 octobre.

9,8 ou 8,1 : pourquoi les notes divergent

L’équipe CVE du noyau note la faille 9,8 sur 10 en CVSS 3.1 : attaque par le réseau, sans compte, sans action de la victime, avec une complexité jugée faible. Ubuntu reprend 9,8 avec une priorité « haute », et Red Hat la classe « critique » à 9,8, en précisant qu’une exécution de code fiable exige de maîtriser finement la mémoire du noyau. SUSE et Oracle retiennent 8,1, parce qu’ils jugent l’attaque complexe : il faut gagner une course entre deux processeurs. Les deux lectures se défendent ; aucune ne dit qu’on peut attendre.

Ce qu’Anthropic a démontré, et ce qui reste inconnu

Le 27 octobre, l’équipe Frontier Red Team d’Anthropic a publié un compte rendu de ses recherches, dont un chapitre porte sur cette faille. Selon ce texte, un attaquant distant peut envoyer des paquets à un serveur Linux dont un service écoute en Multipath TCP, et y exécuter des commandes en root. L’exploit contourne d’abord la randomisation des adresses du noyau (KASLR) ; dans la preuve de concept, il faut 48 minutes pour obtenir une adresse du noyau, puis quelques minutes de plus pour exécuter des commandes. Détail qui compte pour la détection : une course perdue fait seulement échouer la poignée de main TCP, sans planter le serveur. L’attaquant peut donc recommencer sans se faire remarquer par une panne.

Ce qui reste inconnu au 2 novembre :

• Le code n’est pas public. La publication d’Anthropic ne le diffuse pas ; selon TuxCare, qui édite KernelCare, ni le code, ni la version du noyau, ni la configuration testée n’ont été divulgués, et aucune reproduction indépendante n’a été publiée (TuxCare, 30 octobre). L’équipe noyau de CloudLinux écrit n’avoir pas reproduit l’exploit (CloudLinux).
• Aucune exploitation réelle n’est signalée. La faille ne figure pas au catalogue des vulnérabilités exploitées de la CISA (version du 30 octobre, consultée le 2 novembre), et la presse spécialisée ne rapporte aucune attaque confirmée (BleepingComputer, 30 octobre).
• Le correctif, lui, est public depuis le 1^er octobre. Ce n’est pas une faille « zero-day » : quiconque lit le code du noyau sait depuis un mois où chercher. C’est pour cela que la fenêtre actuelle doit servir à corriger.

Suis-je concerné ? Quatre vérifications

Ces commandes se lancent en SSH sur le serveur. Sur un hébergement mutualisé, vous n’avez pas à le faire : voyez plus bas.

1. Qui fournit le noyau ?

systemd-detect-virt

La réponse kvm, vmware, microsoft ou none (machine physique) signifie que le noyau qui tourne est le vôtre : c’est à vous de le mettre à jour. La réponse lxc ou openvz signifie que votre serveur est un conteneur qui partage le noyau de la machine hôte : seul celui qui administre l’hôte peut le corriger. Le même raisonnement vaut pour Docker : un conteneur n’a pas de noyau à lui, c’est celui du serveur qui l’héberge qu’il faut mettre à jour.

2. Quelle distribution, quel noyau ?

cat /etc/os-release
uname -r

La première ligne donne le nom et la version du système (Ubuntu 24.04, AlmaLinux 9…), la seconde la version du noyau en service. Un noyau 4.4 ou plus récent est potentiellement touché ; il est corrigé si sa version atteint celle que donne votre distribution dans le tableau ci-dessous. Sur Debian, uname -r ne montre pas la révision du paquet : uname -v l’affiche, sous la forme « Debian 6.1.190-1 ».

3. Un service écoute-t-il en MPTCP ?

sysctl net.mptcp.enabled
sysctl net.ipv4.tcp_migrate_req   # 0 attendu
sudo ss -lnMp

La première commande dit si le noyau autorise Multipath TCP (1) ou non (0). Selon AlmaLinux et CloudLinux, MPTCP est désactivé d’origine sur leurs systèmes (CloudLinux 8, 9 et 10). La deuxième concerne le second chemin que décrit le communiqué du noyau, la migration des demandes de connexion entre sockets : elle doit répondre 0, sa valeur d’origine. La troisième liste les services réellement à l’écoute en MPTCP. Une liste vide est la situation la plus courante, à une exception près : depuis Go 1.24, les programmes écrits en Go écoutent en MPTCP par défaut quand le noyau le permet (notes de version de Go 1.24). Un outil réseau, un agent de supervision ou un VPN maillé compilé en Go peut donc ouvrir un tel accès sans que personne l’ait décidé.

4. Faut-il couper MPTCP ?

Si personne ne s’en sert, oui, mais en sachant ce que cela vaut. AlmaLinux et CloudLinux le disent tous deux : le défaut est dans le TCP ordinaire, et un serveur sans MPTCP doit quand même être corrigé. Couper MPTCP ferme le chemin démontré, pas les autres.

echo 'net.mptcp.enabled = 0' | sudo tee /etc/sysctl.d/90-disable-mptcp.conf
sudo sysctl -w net.mptcp.enabled=0

Le réglage ne vaut que pour les sockets créées ensuite : relancez les services qu’affichait ss -lnMp. Et il ne vaut pas pour les conteneurs qui ont leur propre espace réseau, où il faut le poser aussi.

Où en est votre distribution

Relevé fait le 2 novembre 2026 sur les pages des éditeurs. Ces états changent d’un jour à l’autre : avant d’agir, rouvrez la page de votre distribution, citée dans le tableau et dans les sources.

Quelques précisions que le tableau ne peut pas porter :

• Ubuntu affiche pour 22.04, 24.04 et 26.04 « work in progress » avec un numéro de version : c’est le noyau en préparation, pas un paquet disponible. La fiche ne mentionne pas de correctif à chaud (Livepatch). Les noyaux des variantes pour l’informatique en nuage (linux-aws, linux-azure, linux-gcp…) ont chacun leur ligne et leur numéro.
• Debian 11 n’apparaît pas dans le suivi de sécurité de Debian pour cette faille. Un serveur encore sous Debian 11 doit passer en version 12 ou 13.
• Red Hat écrit accélérer la préparation des correctifs, sans date. Les distributions qui en reconstruisent les paquets, comme Rocky Linux, attendent en général sa publication ; AlmaLinux, lui, a mis ses noyaux en test sans attendre Red Hat.
• Oracle Linux : seuls les noyaux UEK figurent dans les avis. Le noyau compatible Red Hat (paquet kernel) n’y est pas cité : traitez-le comme un RHEL.
• SUSE a publié les noyaux corrigés de SLES 16.0, d’openSUSE Leap 16.0 et de SLES 15 SP4 à SP6 (LTSS) ; ceux de SLES 15 SP7 sont en préparation, et openSUSE Leap 15.6 est touché, sans correctif (fiche SUSE).
• CloudLinux déploie ses noyaux par étapes : un serveur peut ne pas les voir encore alors que l’avis les annonce. dnf list --available kernel montre ce que votre dépôt propose réellement.

En attendant le correctif : la règle nftables de Red Hat

Pour atteindre le code fautif, un paquet de demande de connexion doit porter des options IPv4. Un en-tête IPv4 sans option mesure cinq mots de 32 bits, soit 20 octets ; au-delà, il en porte. Red Hat propose donc de rejeter tout paquet TCP entrant dont l’en-tête IPv4 dépasse cinq mots. Les options TCP habituelles (taille de segment, horodatage…) sont dans l’en-tête TCP, pas dans l’en-tête IP : elles passent toujours.

Poser la règle

Créez un fichier cve-2026-98432.nft avec le contenu publié par Red Hat :

table inet cve_2026_98432 {
    chain input {
        type filter hook input priority -310; policy accept;
        ip protocol tcp ip hdrlength > 5 counter drop
    }
}

Puis vérifiez la syntaxe, chargez la règle et contrôlez qu’elle est en place :

sudo nft --check --file cve-2026-98432.nft
sudo nft --file cve-2026-98432.nft
sudo nft list table inet cve_2026_98432

Si la commande nft manque, le paquet s’appelle nftables sur Debian, Ubuntu et les systèmes de la famille Red Hat. La règle vit dans sa propre table : elle ne modifie pas celles que gère déjà votre pare-feu (firewalld, ufw, celui de Plesk ou CSF sur cPanel). Le compteur affiché par la dernière commande indique combien de paquets ont été rejetés ; sur un serveur web ordinaire, il ne devrait guère bouger.

Ce qu’il faut savoir avant

• Essayez-la d’abord hors production. Red Hat prévient qu’elle peut perturber certains usages ; elle est à proscrire sur un réseau qui repose sur les étiquettes de sécurité CIPSO/NetLabel, qui passent par des options IPv4 (mise en garde d’AlmaLinux).
• Elle ne survit pas au redémarrage telle quelle. Si vous redémarrez avant d’avoir le noyau corrigé, rechargez-la.
• Elle ne couvre pas tout. Accrochée au point d’entrée input, elle ne filtre que les paquets destinés au serveur lui-même : le trafic transmis à des conteneurs ou à des machines virtuelles qui ont leur propre pile réseau ne la traverse pas. IPv6 n’en a pas besoin.
• Elle n’est pas un correctif. Red Hat le dit en toutes lettres : le filtrage réduit l’exposition, il ne remplace pas la mise à jour.

La retirer

Une fois le serveur redémarré sur un noyau corrigé :

sudo nft delete table inet cve_2026_98432

Installer le noyau corrigé, puis redémarrer

Dès que votre distribution publie le noyau, la procédure est courte, mais elle impose une coupure : le nouveau noyau ne prend effet qu’au démarrage suivant. Prévoyez un créneau creux, une sauvegarde récente de vos données, et un moyen de reprendre la main si la machine ne revient pas (console de secours, accès à l’espace client de votre hébergeur). Le noyau précédent reste en général installé et sélectionnable au démarrage : c’est votre retour arrière.

Debian et Ubuntu

sudo apt update
sudo apt upgrade
ls /var/run/reboot-required 2>/dev/null && echo "Redémarrage nécessaire"   # Ubuntu
sudo reboot

AlmaLinux, Rocky Linux, CloudLinux, RHEL

sudo dnf update 'kernel*'
sudo dnf needs-restarting -r
sudo reboot

Pour prendre les noyaux qu’AlmaLinux a mis en test, l’éditeur donne la marche à suivre, à réserver à une machine que vous pouvez redémarrer et surveiller :

sudo dnf install -y almalinux-release-testing
sudo dnf update 'kernel*' --enablerepo=almalinux-testing
sudo reboot
# après le redémarrage, désactiver le dépôt de test
sudo dnf config-manager --disable almalinux-testing

Plesk et cPanel n’ont rien de particulier à faire : le noyau se met à jour par les paquets du système, et leurs services repartent au démarrage. Une mise à jour automatique du système peut installer le noyau sans redémarrer : c’est le cas où l’on se croit protégé à tort.

Le correctif à chaud, quand il existe

KernelCare, l’outil de correctifs à chaud de TuxCare, applique le correctif sans redémarrage. Au 30 octobre, il était publié pour Debian 13 et en préparation pour Debian 12, Oracle UEK et les systèmes de la famille Red Hat 8, 9 et 10 (dont AlmaLinux et CloudLinux), sans date pour Ubuntu (TuxCare). Pour savoir si votre serveur l’a reçu, CloudLinux recommande :

kcarectl --patch-info | grep CVE-2026-98432

et non kcarectl --info, qui ne liste pas les CVE. Une réponse vide signifie que le correctif n’est pas appliqué.

Vérifier après

uname -r
rpm -q kernel        # famille Red Hat
uname -v             # Debian : révision du paquet

Comparez avec la version du tableau. Si uname -r affiche encore l’ancien noyau alors que le nouveau est installé, le serveur a redémarré sur l’ancien : vérifiez l’entrée par défaut du chargeur de démarrage. Retirez ensuite la règle nftables, puis jetez un œil aux journaux du démarrage (journalctl -b -p err) : le guide pour lire les journaux d’un serveur en production détaille la lecture.

Peut-on savoir si quelqu’un a essayé ?

Honnêtement, difficilement. Aucun des avis consultés ne donne d’indicateur de compromission pour cette faille, et une tentative ratée ne fait, d’après Anthropic, qu’échouer une poignée de main TCP, ce qu’aucun journal applicatif ne note. Deux signaux méritent quand même un coup d’œil :

• Des messages d’erreur du noyau liés au réseau, ou un plantage inexpliqué : journalctl -k pour le démarrage en cours, journalctl -k -b -1 pour le précédent, last -x reboot pour la liste des redémarrages.
• Le compteur de la règle nftables, s’il grimpe : quelqu’un envoie à votre serveur des paquets porteurs d’options IPv4, ce qu’aucun visiteur ordinaire ne fait.

Une exploitation réussie donne les droits root ; à ce niveau, l’attaquant peut effacer ses traces. Si vous avez un doute sérieux, la démarche est celle de toute intrusion : préserver les journaux avant de nettoyer, changer tous les secrets, reconstruire plutôt que réparer. Notre guide pour renforcer durablement la sécurité d’un hébergement décrit cette remise en état.

En hébergement mutualisé : rien à installer

Sur un mutualisé, vous n’avez ni l’accès root ni la main sur le noyau : c’est l’hébergeur qui le met à jour et qui redémarre ses serveurs. Il n’y a donc aucune commande à lancer de votre côté. La seule question utile, si elle vous inquiète, est à lui poser : le noyau de mon serveur est-il corrigé contre CVE-2026-98432, ou protégé en attendant ? Sur CloudLinux, plateforme fréquente en mutualisé, la réponse peut être un correctif à chaud plutôt qu’un redémarrage.

Ce qui reste à votre charge en mutualisé n’a pas changé : un CMS, un thème et des extensions à jour. Les failles WordPress d’octobre le rappellent : le site et le serveur sont deux étages, chacun avec son responsable.

Côté tunisien : le tunCERT et vos obligations

Le tunCERT a publié le 2 novembre le bulletin tunCERT/Vuln.2026-688, « Noyau systèmes Linux », consacré à CVE-2026-98432 : il la classe comme permettant l’exécution de code arbitraire à distance, demande de mettre à jour les systèmes vulnérables et renvoie aux fiches d’Ubuntu, de Red Hat, de Debian et de SUSE. Ce sont ces avis d’éditeurs, cités dans le tableau plus haut, qui donnent la version corrigée de votre noyau.

Si votre serveur traite des données personnelles ou relève des organismes visés par le décret-loi n° 2023-17 sur la cybersécurité, une compromission n’est pas qu’une affaire technique. Nous avons détaillé, à propos de PHP2Shell, ce que la loi tunisienne demande après une intrusion : obligation de sécurité de la loi organique 2004-63, signalement des incidents pour les organismes du décret-loi, et les coordonnées du tunCERT. Tout s’applique ici à l’identique.

Vous avez un VPS ou un dédié chez NovaHoster

Sur nos VPS et nos serveurs dédiés sans option d’infogérance, le système et ses mises à jour sont de votre ressort (sur un dédié, votre quota annuel d’infogérance peut y être consacré) : la démarche décrite ici est la vôtre. Si un point vous bloque (choix du noyau, règle nftables, redémarrage qui ne revient pas), ouvrez un ticket en indiquant la sortie de cat /etc/os-release et de uname -r ; le guide pour ouvrir une demande de support montre ce qui fait gagner du temps.

Si votre serveur est sous infogérance, les correctifs du système et des services font partie du travail de notre équipe ; vous restez juge de la compatibilité de vos applications.

Sources

Pages consultées le 2 novembre 2026.

• Noyau Linux — communiqué CVE-2026-98432 de l’équipe CVE du noyau (versions corrigées, CVSS 3.1 : 9,8) ; commit e3f33b0a1d89, « ipv4: free inet_opt and ireq_opt after an RCU grace period » (1^er octobre 2026)
• Ubuntu — fiche CVE-2026-98432 (publiée le 15 octobre, mise à jour le 30 octobre 2026)
• Red Hat — fiche CVE-2026-98432 ; bulletin RHSB-2026-016 (30 octobre 2026)
• Debian — suivi de sécurité, CVE-2026-98432
• SUSE — fiche CVE-2026-98432 (mise à jour du 31 octobre 2026)
• Oracle Linux — fiche CVE-2026-98432 (avis du 16 octobre 2026)
• AlmaLinux — CVE-2026-98432: Patched kernels available in testing (30 octobre 2026)
• CloudLinux — état de CVE-2026-98432 pour CloudLinux (30 octobre 2026, 22 h 55 UTC)
• Anthropic — compte rendu de la Frontier Red Team (27 octobre 2026)
• ANCS — liste des vulnérabilités ; tunCERT/Vuln.2026-688 (2 novembre 2026)
• CISA — catalogue des vulnérabilités exploitées (version 2026.10.30)
• Go — notes de version de Go 1.24
• Éditeur de KernelCare — TuxCare (30 octobre 2026) : état de KernelCare et absence de code publié
• Presse spécialisée, pour l’absence d’exploitation confirmée — BleepingComputer (30 octobre 2026)