Faille du noyau Linux CVE-2026-98432 : root à distance sans authentification, noyaux à installer

La réponse courte : CVE-2026-98432 est une faille critique du code TCP IPv4 du noyau Linux, présente depuis la version 4.4. Elle peut permettre à un attaquant distant, sans authentification et sans action d’un utilisateur, d’exécuter des commandes en root. Le maCERT de la DGSSI l’a signalée le 30 octobre 2026. Aucune exploitation n’est confirmée à ce jour, mais les correctifs arrivent distribution par distribution : installez le noyau corrigé, redémarrez, puis vérifiez le noyau réellement actif.

Au Maroc, cette alerte concerne une grande partie des serveurs d’entreprise : serveurs web, hébergement Odoo, hyperviseurs Proxmox, machines cloud et appliances basées sur Linux.

Ce qui est touché et ce qu’il faut installer

Produit	Versions touchées	Version corrigée
Noyau Linux officiel	à partir de 4.4	5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10, 7.3
Debian 12 (Bookworm)	noyau 6.1 antérieur au correctif	6.1.190-1 (DLA-4841-1) ; pour linux-6.12 : 6.12.113-1~deb12u1 (DLA-4850-1)
Debian 13 (Trixie)	noyau 6.12 antérieur au correctif	6.12.113-1 (DSA-6568-1)
Red Hat Enterprise Linux 8, 9, 10	noyaux antérieurs aux correctifs ; RHEL 6 et 7 non touchés	RHSA-2026:93414 et 93415 (RHEL 8), RHSA-2026:93412 (RHEL 9), RHSA-2026:93413 (RHEL 10)
Ubuntu 22.04, 24.04, 26.04, 26.10	indiquées « vulnérables, correctif en cours » au 5 novembre	annoncées : 5.15.0-203.213, 6.8.0-149.149, 7.0.0-43.43, 7.3.0-10.10
Proxmox VE, noyau 7.0	7.0.14-24-pve et antérieurs	7.0.14-25-pve et suivants
Amazon Linux 2 et 2023	familles de noyaux listées par AWS	paquets indiqués corrigés dans le suivi AWS

Sources : fiche CVE du noyau Linux, suivis de sécurité Debian, Red Hat, Ubuntu et Amazon, forum officiel Proxmox. Ces états évoluent chaque jour : vérifiez le suivi de votre distribution avant d’intervenir. Pour Proxmox, une autre branche de noyau doit être vérifiée dans le journal des modifications du paquet ou auprès du support.

Côté technique, il s’agit d’une utilisation de mémoire après libération (use-after-free). Lors de l’établissement d’une connexion TCP, des options IPv4 peuvent être libérées alors qu’un autre processeur les lit encore, par exemple pour répondre à un SYN retransmis. Le correctif du noyau retarde cette libération. IPv6 n’est pas touché par le premier scénario décrit dans la fiche CVE.

Gravité et exploitation

• Gravité publiée : la fiche CVE du noyau Linux et Red Hat indiquent un score CVSS 3.1 de 9,8 (critique). Amazon retient 8,1 (important) et Oracle Linux la classe « importante ».
• maCERT : le bulletin 70343010/26 du 30 octobre 2026 classe le risque et l’impact au niveau critique. Il renvoie aux bulletins de chaque distribution.
• Exploitation : aucune confirmée. CVE-2026-98432 ne figure pas dans le catalogue CISA KEV du 4 novembre 2026. L’avis Fortinet indique « Known Exploited : No » et Sophos dit n’avoir connaissance d’aucune exploitation publique.
• Preuve de faisabilité : selon BleepingComputer et CSO Online, Anthropic rapporte qu’un modèle de recherche Claude non publié a écrit, en laboratoire, un exploit donnant un accès root à distance sur un serveur doté d’un service MPTCP, en 53 minutes environ. Le code n’a pas été publié.
• Signal à surveiller : Aikido relaie un signalement du chercheur Marcus Hutchins sur ce qui ressemble à des balayages d’internet à la recherche de serveurs MPTCP. Ce n’est pas une preuve d’attaque, mais cela plaide pour ne pas attendre.

Le cas des appliances : Fortinet, Sophos et les autres

Le 2 novembre 2026, Fortinet a publié l’avis FG-IR-26-188 : son enquête est en cours et la liste des produits à l’étude comprend notamment FortiOS, FortiManager, FortiAnalyzer, FortiMail, FortiWeb, FortiSwitch et FortiAP. L’avis ne confirme à ce stade ni produit touché ni version corrigée, et n’annonce pas de correctif virtuel. Inutile donc de conclure que vos FortiGate sont vulnérables : suivez l’avis et notre méthode de mise à jour de FortiOS.

Sophos a également publié un avis le 2 novembre, annonçant enquêter sur ses produits, et invite à inclure les appliances tierces basées sur Linux dans l’inventaire. Faites de même pour vos NAS, IPBX et boîtiers de sécurité : demandez à chaque éditeur son état de correction.

Les mesures d’attente

Si le noyau corrigé n’est pas encore disponible ou si le redémarrage doit être planifié :

1. Réduire l’exposition : limiter les ports TCP accessibles depuis internet aux seuls services nécessaires, et aux adresses de confiance lorsque c’est possible.
2. Filtrer les paquets TCP IPv4 portant des options IP. Red Hat publie la règle nftables ci-dessous. Elle réduit l’exposition sans l’éliminer et peut perturber certains usages : testez-la d’abord. Elle ne survit pas à un redémarrage.

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

Enregistrez-la dans cve-2026-98432.nft, vérifiez avec sudo nft --check --file cve-2026-98432.nft, appliquez avec sudo nft --file cve-2026-98432.nft. Une fois le noyau corrigé actif, retirez-la avec sudo nft delete table inet cve_2026_98432.

3. Ne pas compter sur la seule désactivation de MPTCP. Selon Red Hat, net.mptcp.enabled=0 bloque une méthode d’exploitation, pas la faille. RHEL désactive MPTCP par défaut et reste vulnérable.

Les vérifications à faire

• Inventorier tous les hôtes Linux : machines virtuelles, nœuds Proxmox, serveurs cloud, conteneurs et leurs hôtes, machines oubliées.
• Contrôler le noyau actif avec uname -r après redémarrage. Un noyau installé mais pas chargé ne corrige rien.
• Comparer avec la version de votre distribution, pas avec la version officielle du noyau, car les correctifs sont rétroportés.
• Traiter en premier les serveurs accessibles depuis internet.
• Surveiller les redémarrages inexpliqués et les plantages du noyau, que la fiche CVE cite comme conséquence possible. En cas de doute, appliquez notre plan de réponse à incident pour la première heure.

Notre lecture pour les entreprises au Maroc

Cette faille rappelle qu’un serveur à jour n’est pas forcément protégé : sans redémarrage, le correctif reste inactif. Sur un hyperviseur, cela suppose de déplacer ou d’arrêter les machines virtuelles, donc de préparer l’intervention. Notre méthode de gestion des correctifs aide à organiser ce type de campagne. Pour les organismes concernés, la loi 05-20 et les exigences de la DGSSI imposent aussi de traiter les bulletins du maCERT.

Comment nous pouvons vous aider

Nous pouvons recenser vos serveurs Linux, comparer leurs noyaux aux versions corrigées, poser le filtre d’attente si besoin et planifier les redémarrages. Sur vos clusters, nous intervenons en tant que partenaire Proxmox au Maroc, avec notre offre d’intégration et de support Proxmox. Pour vos pare-feu, nous suivons l’avis de l’éditeur en tant qu’intégrateur Fortinet au Maroc. Nous assurons ensuite la supervision 24/7, avec une prise en charge des incidents critiques en moins de 15 minutes.

Découvrez notre approche de la cybersécurité des entreprises au Maroc, puis demandez votre audit initial offert : nous vous répondons sous 24 h ouvrées.

Sources : maCERT : bulletin 70343010/26, fiche CVE-2026-98432, NVD CVE-2026-98432, Red Hat RHSB-2026-016, suivi Debian, suivi Ubuntu, suivi Amazon Linux, Oracle Linux, forum Proxmox, avis Fortinet FG-IR-26-188, avis Sophos, catalogue CISA KEV, BleepingComputer, CSO Online, Aikido.