Faille critique du noyau Linux (CVE-2026-98432) : quels serveurs sont touchés et comment l'atténuer en attendant le correctif

Publié le 6 novembre 2026 · L'équipe mitza.es

Une grande partie de l'infrastructure des entreprises fonctionne sous Linux sans que personne s'en souvienne : le serveur web de la boutique en ligne, la machine virtuelle qui héberge le logiciel de gestion, un conteneur dans le cloud ou un équipement réseau. Le 30 octobre 2026, Red Hat a publié un bulletin de sécurité sur une faille du noyau Linux (le cœur du système) qu'il identifie comme CVE-2026-98432 et qu'il note 9,8 sur 10. Le bulletin a été mis à jour le 4 novembre. Cet article résume ce que Red Hat a confirmé au 6 novembre 2026, sans aller au-delà de ce que disent ses avis.

Ce que dit Red Hat

• Identifiant et gravité : CVE-2026-98432, bulletin RHSB-2026-016. Score CVSS 3.1 de 9,8 avec le vecteur AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, c'est-à-dire : l'attaque se fait par le réseau, de façon simple, sans privilèges et sans intervention d'aucun utilisateur. Red Hat et le registre CVE s'accordent sur ce chiffre. Pour les produits Red Hat, la sévérité est critique.
• Ce qui dysfonctionne : une condition de concurrence dans le traitement du réseau TCP. Lorsque le système traite simultanément des demandes de connexion retransmises ou des migrations de sockets, les options du socket peuvent être libérées de la mémoire alors qu'une autre partie du système les utilise encore. En termes simples : le noyau « jette » une donnée dont il a encore besoin, et un attaquant pourrait exploiter cette brèche.
• Ce dont l'attaquant a besoin : envoyer à un système qui accepte des connexions TCP en IPv4 des paquets avec des options IP et tomber juste sur le moment de deux opérations concurrentes. C'est une attaque à distance et sans authentification, mais elle exige un minutage précis.
• Les conséquences : Red Hat mentionne un déni de service, une corruption de mémoire et une exécution de code à distance. L'exécution fiable de code exige un contrôle précis de la mémoire, c'est donc cette dernière possibilité qui est la plus difficile à obtenir ; l'avis du bulletin la signale toutefois comme possible.
• Dates : publié le 30 octobre 2026 et mis à jour le 4 novembre.

Quels systèmes sont touchés

Red Hat indique comme directement touchés Red Hat Enterprise Linux 8, 9 et 10 et Red Hat OpenShift Container Platform 4 (les nœuds sous RHEL CoreOS). Les produits construits sur le noyau de RHEL, comme Red Hat OpenStack Platform et Red Hat Virtualization, peuvent aussi être touchés. Les systèmes qui acceptent des connexions TCP entrantes sont les plus exposés. Il n'est pas nécessaire que le protocole MPTCP soit actif pour que le risque existe.

Une précaution importante : Red Hat ne documente que ses propres produits et n'indique ni numéros de version du noyau d'origine (upstream) ni paquets corrigés précis (il « accélère la publication des correctifs » ; l'état figure comme « en cours »). Nous n'avons pas pu confirmer l'état dans d'autres distributions comme Debian, Ubuntu, AlmaLinux ou Rocky ; consultez l'avis de sécurité de la vôtre avant de considérer le problème comme écarté.

Est-elle déjà exploitée ?

Ni le bulletin ni la fiche de Red Hat ne disent que la faille est exploitée, et elle ne figure pas comme exploitée dans les informations que nous avons consultées. Cela peut changer à tout moment, et une faille que l'on attaque par le réseau et sans identifiants est un candidat évident. Il convient de la traiter comme un correctif prioritaire, pas comme une tâche du prochain créneau de maintenance.

Que faire dès aujourd'hui : la checklist

1. Faites l'inventaire. Notez quels serveurs, machines virtuelles, conteneurs et équipements réseau de votre entreprise fonctionnent sous Linux, avec quelle distribution et qui les gère. S'ils sont gérés par un prestataire ou un hébergeur, demandez-lui de confirmer par écrit si vous êtes concerné et quand il appliquera le correctif.
2. Vérifiez la version et la distribution. Sur un serveur Linux, cat /etc/os-release vous donne la distribution et uname -r la version du noyau.
3. Appliquez la mise à jour du noyau dès qu'elle existe pour votre distribution. Un nouveau noyau exige de redémarrer le système (sauf si vous utilisez le correctif à chaud), alors planifiez-le. Red Hat affirme que c'est la « seule solution complète ».
4. Tant qu'il n'y a pas de correctif, appliquez la mesure d'atténuation temporaire. Red Hat propose de rejeter les paquets TCP entrants qui portent des options IP, avec une règle nftables (voir ci-dessous).
5. Limitez ce qui est exposé. Un serveur qui n'a besoin de répondre qu'à vous ne devrait pas accepter de connexions venant de tout internet. Examinez le pare-feu : si vous voulez revoir comment il s'organise, consultez notre guide qu'est-ce qu'un pare-feu et de quoi une PME a besoin.
6. Ayez une sauvegarde récente et testée avant de toucher à quoi que ce soit : la règle 3-2-1 reste votre assurance.

La mesure d'atténuation temporaire de Red Hat

Red Hat propose une règle nftables qui rejette les paquets TCP IPv4 comportant des options IP. On l'enregistre dans un fichier (par exemple, cve-2026-98432.nft) avec ce contenu :

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

On la vérifie avec sudo nft --check --file cve-2026-98432.nft et on l'applique avec sudo nft --file cve-2026-98432.nft. Deux mises en garde de Red Hat : la règle ne persiste pas après un redémarrage, et elle ne remplace pas le correctif. Une fois le noyau mis à jour, on la retire avec sudo nft delete table inet cve_2026_98432. Testez d'abord la règle dans un environnement contrôlé et, si vous n'êtes pas sûr de ce que vous faites sur un serveur de production, laissez votre administrateur l'appliquer.

Ce que Red Hat déconseille : désactiver MPTCP (net.mptcp.enabled=0) n'est pas une mesure d'atténuation complète et, de fait, RHEL le fournit désactivé par défaut et reste vulnérable. On ne peut pas non plus utiliser ss -Mlnp comme test d'exposition. Sur OpenShift, le trafic entre pods n'a pas encore de mesure d'atténuation ; Red Hat renvoie à un article de support spécifique.

Et si je ne gère pas de serveurs ?

Si votre site est sur un hébergement mutualisé ou géré, ce correctif relève de la responsabilité du prestataire : le plus raisonnable est de lui demander s'il l'a déjà appliqué. Si vous avez un serveur virtuel (VPS) ou un serveur à vous, c'est à vous de vous en occuper, ou à la personne qui l'administre. Dans tous les cas, c'est une bonne occasion de fixer un délai maximal de correctif pour les failles critiques et de vérifier que votre prestataire vous informe quand une telle situation se présente. Si vous envisagez d'héberger votre infrastructure en dehors de vos locaux, ce guide sur le cloud computing pour PME vous aide à décider ce que chacun gère.

Questions rapides

Suis-je concerné si j'utilise Windows ?

Pas par cette faille, qui est celle du noyau Linux. Si vous utilisez Windows, le calendrier pertinent est celui des mises à jour mensuelles ; par exemple, en octobre, il y a eu un Patch Tuesday avec plus de 1 400 vulnérabilités.

Que signifie « 9,8 » et est-ce le maximum ?

L'échelle CVSS va jusqu'à 10. Un 9,8 indique un risque très élevé : accès par le réseau, sans identifiants et avec un impact total sur la confidentialité, l'intégrité et la disponibilité. La gravité réelle dépend aussi de l'exposition du système et de la difficulté de l'exploiter, ce qui exige ici un minutage précis.

Cela a-t-il un rapport avec la réglementation NIS2 ?

La gestion des vulnérabilités et des fournisseurs fait partie des mesures attendues des entreprises visées par la directive. Vous en trouverez le contexte dans notre guide sur la réglementation NIS2 pour les PME.

Comment Mitza peut vous aider

Nous examinons quels serveurs et équipements vous exposez, nous vérifions les versions, nous appliquons correctifs et mesures d'atténuation et nous documentons le processus. Découvrez comment nous concevons la maintenance informatique pour PME ou exposez-nous votre cas depuis la page de contact.

À lire aussi : OpenSSH 10.6p2 et la faille des mots de passe longs sur Alpine Linux et le ransomware dans les entreprises espagnoles.