CVE-2026-98432 : faille TCP du noyau Linux notée 9.8, ce qu'on sait et comment patcher son VPS

Le 15 octobre 2026, le projet noyau Linux a publié l'avis de sécurité CVE-2026-98432, une vulnérabilité de type use-after-free dans la pile TCP IPv4 du noyau. Le score CVSS 3.1 attribué par le CNA du noyau et repris par le NVD est de 9.8 (critique), mais plusieurs évaluateurs le contestent en raison de la complexité réelle de l'attaque. Présente depuis le noyau 4.4 (2016), cette faille touche la gestion des options IP lors de l'établissement d'une connexion TCP. Elle peut provoquer un plantage du noyau à distance (kernel panic) sur tout système d'exploitation Linux vulnérable, sans authentification. Au 29 octobre, aucun code d'exploitation public n'a été identifié, la faille est absente du catalogue KEV de la CISA et son score EPSS reste sous 1 %. Debian a publié ses paquets corrigés. Ubuntu et Red Hat n'ont pas encore livré de mise à jour. Si vous administrez un serveur VPS Linux, un serveur dédié ou toute machine virtuelle exposée sur Internet, voici ce qu'il faut savoir et comment agir.

Sources : advisory du noyau Linux, Debian Security Tracker, Ubuntu CVE Tracker, Red Hat Customer Portal.

Comprendre la faille CVE-2026-98432

La vulnérabilité se situe dans la fonction tcp_v4_syn_recv_sock(), appelée lors de l'étape finale du three-way handshake TCP. Quand un serveur reçoit l'ACK d'un client et crée le socket enfant, cette fonction transfère les options IP de la demande de connexion (ireq_opt) vers le nouveau socket sans en faire de copie. Les deux structures partagent le même pointeur vers la zone de mémoire vive (RAM) allouée pour ces options.

Le problème survient lorsqu'un SYN retransmis pour la même connexion est traité au même moment sur un autre processeur. Le noyau tente alors de construire un SYN-ACK en lisant les options IP via tcp_v4_send_synack(), mais celles-ci ont déjà été libérées par le socket enfant. C'est une condition de course (race condition) entre deux CPU : l'un crée le socket enfant et libère la mémoire, l'autre lit ces mêmes options pour fabriquer le SYN-ACK. Gagner cette course reste aléatoire : le résultat dépend du timing exact entre les processeurs, ce qui rend l'exploitation non déterministe.

Un second chemin existe lors de la migration de demandes de connexion (paramètre net.ipv4.tcp_migrate_req), mais ce paramètre est désactivé par défaut (valeur 0). IPv6 n'est pas touché par le cas principal : seul le code IPv4 dans net/ipv4/tcp_ipv4.c et net/ipv4/af_inet.c est concerné.

Le correctif remplace les appels kfree() par kfree_rcu() dans les fonctions inet_sock_destruct() et tcp_v4_reqsk_destructor(), ce qui garantit que la zone de RAM n'est libérée qu'après une période de grâce RCU, quand plus aucun CPU ne peut y accéder.

Pourquoi le score CVSS 9.8 est discuté

Le score CVSS 3.1 de 9.8 attribué par le CNA du noyau Linux considère la complexité d'attaque comme basse (AC:L) et un impact total sur la confidentialité, l'intégrité et la disponibilité. Ce score est repris tel quel par la base NVD.

Deux réévaluations abaissent sensiblement ce score :

Le point de désaccord porte sur la complexité d'exploitation. Pour déclencher le use-after-free, un attaquant doit gagner une course entre deux CPU au moment précis de l'établissement d'une connexion TCP. Provoquer un plantage du noyau (kernel panic) à distance est envisageable, mais gagner cette course reste aléatoire, ce qui rend l'exploitation non déterministe. Transformer ce plantage en prise de contrôle du serveur supposerait de manipuler le contenu exact de la mémoire vive libérée au bon moment, ce qui reste théorique en l'absence de code public. Red Hat ne retient d'ailleurs que l'impact sur la disponibilité (déni de service), sans impact confirmé sur la confidentialité ni l'intégrité.

Quels serveurs et systèmes d'exploitation sont concernés

Tout système d'exploitation Linux dont le noyau est compris entre la version 4.4 et les versions corrigées ci-dessous est vulnérable. En pratique, toute machine virtuelle ou serveur physique qui accepte des connexions TCP sur une adresse IP publique en IPv4 est potentiellement exposée :

• Serveurs VPS Linux sous Debian, Ubuntu, CentOS Stream ou toute distribution utilisant un noyau non corrigé ;
• Serveurs dédiés avec le noyau stock du système d'exploitation installé ;
• Serveurs web (Apache, Nginx) hébergeant des sites web, serveurs de bases de données (MySQL, PostgreSQL), serveurs DNS, serveurs de jeu (FiveM, Minecraft, Rust) ou tout autre service réseau tournant sur un serveur virtuel ou un serveur dédié sous Linux ;
• Conteneurs (Docker, LXC) : le conteneur partage le noyau de l'hôte, donc si le noyau de la machine hôte est vulnérable, tous les conteneurs le sont aussi.

En cas de plantage du noyau (kernel panic), tous les services hébergés sur le serveur privé virtuel sont interrompus : sites web, bases de données, serveur DNS, panel d'administration, scripts applicatifs et toute application écoutant sur le réseau. L'interruption dure le temps du redémarrage de la machine virtuelle.

Ne sont pas concernés : les noyaux antérieurs à 4.4, les connexions IPv6 uniquement (chemin de code différent), les serveurs VPS ou dédiés sous Windows, et RHEL 7 (code absent).

État des correctifs par distribution

Les correctifs ont été intégrés dans les branches stables du noyau Linux en amont (versions 5.10 à 7.2). L'avis de sécurité CVE-2026-98432 a été rendu public le 15 octobre 2026 : cette date est celle de la publication de l'advisory, pas celle des correctifs eux-mêmes. Les distributions ont ensuite préparé et publié leurs propres paquets (packages) de mise à jour du noyau.

Debian : paquets corrigés disponibles

• Debian 13 Trixie : DSA-6568-1, noyau 6.12.113-1
• Debian 12 Bookworm : DLA-4841-1, noyau 6.1.190-1

Ubuntu : correctifs en cours de préparation

Ubuntu 22.04 LTS, 24.04 LTS et 26.04 LTS : au 29 octobre, les paquets corrigés du noyau sont en cours de préparation (work in progress) mais pas encore disponibles dans les dépôts officiels. Surveillez le tracker Ubuntu et appliquez la mise à jour dès sa publication.

Red Hat et CentOS : correction reportée

Red Hat attribue à cette faille un score CVSS de 5.9 (modéré, complexité haute). L'impact probable retenu est un déni de service (plantage du noyau), avec un potentiel théorique de corruption de la mémoire. Le vecteur CVSS ne retient aucun impact sur la confidentialité (C:N) ni sur l'intégrité (I:N), uniquement sur la disponibilité (A:H). Le correctif est reporté (fix deferred) sur RHEL 8, 9 et 10 sans date annoncée. RHEL 7 n'est pas affecté (code vulnérable absent). Aucun contournement ne remplit les critères de Red Hat Product Security. CentOS Stream, AlmaLinux et Rocky Linux publient leurs correctifs selon leur propre calendrier : vérifiez l'avis de sécurité de votre distribution.

Aucun contournement officiel n'a été publié par les mainteneurs du noyau Linux.

Vérifier si votre serveur VPS est vulnérable

Connectez-vous en SSH à votre serveur VPS ou serveur dédié et affichez la version du noyau du système d'exploitation en cours d'exécution :

uname -r

Comparez le résultat aux versions corrigées du tableau ci-dessus. Un noyau antérieur à la version corrigée de votre branche est vulnérable. Sur Debian ou Ubuntu, vérifiez le paquet noyau installé et les mises à jour disponibles :

dpkg -l linux-image-$(uname -r)
sudo apt update && apt list --upgradable 2>/dev/null | grep linux-image

Sur CentOS Stream, RHEL ou toute distribution RPM, vérifiez le paquet kernel installé et les mises à jour en attente :

rpm -q kernel
sudo dnf check-update kernel

Appliquer le correctif et redémarrer

Avant toute intervention, sauvegardez vos données. La mise à jour du noyau nécessite un redémarrage du serveur pour charger la version corrigée en mémoire vive. Prévoyez une fenêtre de maintenance si votre serveur VPS héberge un service en production.

Debian (Bookworm ou Trixie)

sudo apt update && sudo apt full-upgrade -y
sudo reboot

Après le redémarrage, vérifiez que le nouveau noyau est chargé :

uname -r

Ubuntu (dès la publication du correctif)

sudo apt update && sudo apt full-upgrade -y
sudo reboot

Les commandes sont identiques. Appliquez-les dès que le paquet linux-image corrigé apparait dans les dépôts. Pour configurer la surveillance automatique des mises à jour de sécurité sur votre serveur VPS Ubuntu, consultez notre guide automatiser les mises à jour de sécurité d'un VPS Ubuntu.

CentOS Stream, RHEL, AlmaLinux, Rocky Linux

Au 29 octobre, Red Hat n'a pas publié de noyau corrigé. Pour CentOS Stream, AlmaLinux et Rocky Linux, vérifiez l'avis de sécurité de votre distribution. Dès qu'un noyau corrigé est disponible :

sudo dnf update kernel -y
sudo reboot

VPS KVM : pourquoi c'est à vous d'agir

Sur un VPS Linux KVM comme ceux proposés par ElypseCloud, chaque serveur privé virtuel exécute son propre noyau Linux, chargé dans sa propre mémoire vive (RAM). La virtualisation matérielle (KVM) isole chaque machine virtuelle au niveau du matériel (hardware) : contrairement aux conteneurs (LXC, Docker) qui partagent le noyau de l'hôte, votre serveur virtuel dispose de son propre noyau et de ses propres configurations système. C'est un avantage en matière de sécurité : une faille noyau sur un VPS voisin ne vous atteint pas, et votre système d'exploitation est entièrement sous votre contrôle.

En contrepartie, c'est à vous d'administrer et de maintenir votre noyau à jour. Sur un hébergement mutualisé ou en infogérance, c'est le prestataire qui gère les mises à jour du système d'exploitation et les configurations de sécurité du serveur. Sur un serveur privé virtuel en accès root, cette responsabilité vous revient : appliquez le correctif en SSH, redémarrez et vérifiez la version avec uname -r.

Sécuriser votre serveur VPS après la mise à jour

Patcher le noyau corrige cette faille, mais la sécurité d'un serveur VPS Linux repose sur plusieurs couches de configuration. Profitez de ce redémarrage pour vérifier les points suivants :

• Sauvegardes (backup) : vérifiez que vos sauvegardes automatiques fonctionnent et qu'une copie récente existe sur un stockage distant ou un espace disque dédié (SSD, stockage objet). Un instantané avant chaque mise à jour critique permet de restaurer le serveur virtuel en cas de problème au redémarrage.
• Pare-feu (firewall) : limitez les ports ouverts au strict nécessaire et surveillez la bande passante entrante. Sur un serveur VPS Linux, ufw (Debian/Ubuntu) ou firewalld (CentOS/RHEL) permettent de configurer des règles de filtrage en quelques commandes.
• Services hébergés : si votre serveur virtuel héberge des sites web (Apache, Nginx), des bases de données MySQL ou un serveur DNS, vérifiez que ces services redémarrent correctement après le reboot. Le redémarrage du système d'exploitation relance les services configurés au démarrage.
• Mises à jour automatiques : configurez unattended-upgrades (Debian/Ubuntu) ou dnf-automatic (CentOS/RHEL) pour appliquer les correctifs de sécurité dès leur publication, sans intervention manuelle. Notre guide automatiser les mises à jour de sécurité détaille la procédure.
• Accès SSH : désactivez l'authentification par mot de passe, utilisez des clés SSH et changez le port par défaut. Voir notre guide sécuriser SSH sur VPS Linux.

Pour d'autres actualités sur les vulnérabilités du noyau Linux, consultez nos articles sur les failles ksmbd et sur CVE-2026-46300 Fragnesia.