Critique : faille du noyau Linux CVE-2026-98432 (9,8/10), les serveurs exposés à des attaques à distance

Article rédigé le 30 octobre 2026 à partir des informations publiées jusqu'à cette date. Les correctifs des distributions arrivent au fil de l'eau : vérifiez toujours l'avis de votre distribution avant d'agir.

Une vulnérabilité grave touche le code réseau TCP du noyau Linux. Référencée CVE-2026-98432 et notée 9,8/10 par l'équipe CVE du noyau, c'est une faille de type use-after-free (utilisation après libération de mémoire) déclenchée par des requêtes réseau minutées de façon spécifique. Elle peut être exploitée à distance, sans authentification, et permet au minimum de corrompre la mémoire du noyau, donc de faire planter un serveur vulnérable. Une équipe de recherche affirme en outre être allée beaucoup plus loin en laboratoire.

1. Ce que l'on sait de la faille

• Nature : une condition de concurrence (race condition) dans la phase d'établissement d'une connexion TCP en IPv4. Les options IP de la requête sont libérées sans attendre la fin d'une période de grâce RCU, ce qui laisse un pointeur vers une mémoire déjà libérée.
• Accès : réseau, sans authentification ni interaction.
• Versions touchées : les branches stables du noyau depuis la 4.4, avant les versions corrigées ci-dessous.
• Correctif amont : un commit intitulé « ipv4: free inet_opt and ireq_opt after an RCU grace period », intégré le 15 octobre 2026, jour de la publication de la CVE.

Noyaux amont corrigés

5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 et 7.3. Attention : les distributions reportent les correctifs sur leurs propres numéros de version, si bien que le numéro amont ne dit pas si votre noyau est corrigé. Fiez-vous à l'avis de votre distribution.

2. Un simple plantage, ou plus ?

Le titre de l'alerte qui circule parle de faire planter des serveurs à distance, et c'est bien le risque minimal d'une corruption mémoire du noyau. Mais le tableau est plus sérieux. Le 28 octobre, la Frontier Red Team d'Anthropic a indiqué qu'un modèle non publié avait transformé la faille en une exploitation à distance donnant les droits root, sans interaction, contre des serveurs disposant d'un écouteur MPTCP (Multipath TCP). Les chiffres rapportés : environ 48 minutes pour contourner la protection KASLR, puis cinq minutes de plus pour obtenir un shell.

À mettre en perspective :

• cette démonstration a été réalisée en laboratoire ; l'exploit n'a pas été publié ;
• le lien entre la faille et l'écouteur MPTCP repose, selon les analyses consultées, sur cette seule source ;
• au 29-30 octobre, aucune exploitation dans la nature n'était signalée et la CVE ne figurait pas dans le catalogue des vulnérabilités exploitées de la CISA ;
• les éditeurs ne sont pas d'accord sur la gravité : 9,8 pour l'équipe du noyau et Ubuntu, 8,1 pour SUSE et Amazon, 5,9 pour Red Hat. L'écart tient en grande partie à la fréquence réelle de MPTCP en production.

Le plus prudent est de la traiter comme critique pour les serveurs exposés à Internet, sans attendre que l'exploitation soit confirmée.

3. Où en sont les correctifs ? (au 30 octobre)

Ces informations viennent d'un suivi tiers daté du 30 octobre : confirmez avec l'avis officiel de votre distribution.

4. Que faire dès maintenant ?

Si un noyau corrigé existe pour votre distribution

1. Installez-le (apt upgrade, dnf update kernel, etc.).
2. Redémarrez la machine : un noyau corrigé installé mais non démarré ne protège pas.
3. Vérifiez le noyau actif avec uname -r, puis la présence de la CVE dans le journal des modifications du paquet :

# Debian / Ubuntu
apt changelog linux-image-$(uname -r) 2>/dev/null | grep CVE-2026-98432
[ -f /var/run/reboot-required ] && echo "Redémarrage requis"

# RHEL / Rocky / Alma / Oracle / Amazon Linux
rpm -q --changelog kernel-$(uname -r) | grep CVE-2026-98432
needs-restarting -r

Si aucun correctif n'est encore disponible (Ubuntu, RHEL et dérivés)

Ces mesures réduisent l'exposition, mais ne remplacent pas la mise à jour. Testez-les avant de les généraliser.

• Repérer les écouteurs MPTCP avec ss -Mlnp. Attention : à partir de Go 1.24, les programmes Go utilisent MPTCP par défaut sous Linux, donc des services Go peuvent en ouvrir à votre insu.
• Désactiver MPTCP : sysctl -w net.mptcp.enabled=0. Cela n'arrête pas les écouteurs déjà ouverts : redémarrez les services concernés, puis vérifiez que ss -lnMp ne renvoie plus rien. Pour un programme Go, utilisez GODEBUG=multipathtcp=0. Le réglage n'est pas persistant : ajoutez-le à la configuration système de votre distribution.
• Bloquer les paquets TCP IPv4 qui portent des options IP avec nftables, selon l'analyse publiée par un chercheur qui l'a testée sans lancer l'exploit :

sudo nft add table ip cve_2026_98432
sudo nft add chain ip cve_2026_98432 pre '{ type filter hook prerouting priority -300; }'
sudo nft add rule ip cve_2026_98432 pre meta l4proto tcp ip hdrlength gt 5 counter drop

Cette règle n'est pas persistante, elle abandonne aussi les paquets en transit si le serveur fait du routage, et elle est déconseillée sur les réseaux qui utilisent l'étiquetage CIPSO (SELinux, Smack). Aucun éditeur ne l'a validée officiellement comme mesure de contournement. Après installation du noyau corrigé et redémarrage, retirez-la.

• Prioriser : d'abord les serveurs exposés à Internet avec des ports TCP IPv4, puis ceux qui hébergent des services MPTCP ou Go, puis les machines internes.
• Surveiller les journaux du noyau : journalctl -k | grep -E 'ip_options_build|ip_build_and_send_pkt|skb_under_panic', et alertez sur les paniques et oops noyau des machines exposées.
• Les distributions en fin de vie (Ubuntu 16.04, 18.04, 20.04 sans support étendu) ne recevront probablement pas de correctif : migrez ou isolez-les.

5. Ce que cela change pour un site web ou une application

Ce type de faille se situe sous votre application : ni PHP, ni Node.js, ni Laravel ne vous protègent, et un pare-feu applicatif (WAF) devant un site ne filtre pas le trafic TCP brut vers le serveur. Le correctif passe par le système : noyau à jour, redémarrage planifié, surface réseau réduite (ne laisser ouverts que les ports nécessaires). Sur un VPS, c'est à vous de le faire ; chez un hébergeur mutualisé ou managé, interrogez-le sur son calendrier de correction. Gardez aussi la même discipline pour le reste de la chaîne : voyez notre article sur les failles PHP2Shell, Node2Shell et HTTP2Shell, et nos bonnes pratiques de cybersécurité pour une vue d'ensemble. L'épisode de la faille Axios illustre la même logique côté dépendances.

6. Une tendance à garder en tête

Après PHP2Shell et la faille Brotli, c'est la troisième alerte majeure en quelques jours, et l'intelligence artificielle intervient de plus en plus, aussi bien pour découvrir les failles que pour les transformer en exploits. Le délai entre la publication d'un correctif et l'apparition d'attaques se raccourcit. La meilleure défense reste banale : un inventaire à jour des systèmes et des versions, des mises à jour régulières, un processus de redémarrage maîtrisé et une surveillance des journaux.

Conclusion

CVE-2026-98432 est une faille critique du noyau Linux, exploitable à distance sans authentification, qui risque au minimum de faire planter un serveur et peut, d'après une démonstration de laboratoire, mener à une prise de contrôle root sur les serveurs avec MPTCP. Si votre distribution propose un noyau corrigé, installez-le et redémarrez. Sinon, réduisez l'exposition (MPTCP désactivé, règle nftables, ports limités), surveillez les journaux et suivez l'avis de votre distribution.

Sources à consulter

• pwn.watch : fiche de suivi de CVE-2026-98432
• PatchMon : état des correctifs par distribution (30 octobre 2026)
• RFF : contournements avant le noyau corrigé
• Shield53 : analyse du désaccord sur la gravité
• Anthropic Frontier Red Team : article du 28 octobre 2026 sur l'exploitation en laboratoire
• Avis de votre distribution (Ubuntu, Red Hat, Debian, SUSE, Oracle, Amazon)