État des correctifs CVE-2026-98432 par distribution : RHEL, AlmaLinux, Rocky, Debian et Proxmox sont corrigés, Ubuntu non. Une vérification de cinq minutes et la mesure recommandée pour les serveurs que vous ne pouvez pas encore corriger.
CVE-2026-98432 se trouve dans le code qui accepte chaque nouvelle connexion TCP en IPv4 sur un serveur Linux. L’équipe du noyau et Red Hat la notent toutes deux 9,8 sur 10, et un exploit fonctionnel donnant un accès root à distance a été décrit publiquement. La plupart des distributions offrent maintenant un noyau corrigé : Red Hat a publié ses correctifs le 1er novembre, et Debian, AlmaLinux, Rocky Linux, Oracle Linux, SUSE, Proxmox et une partie d’Amazon Linux ont les leurs. Ubuntu fait figure d’exception : au 2 novembre, aucun noyau corrigé n’est encore disponible. Voici où en est votre distribution, comment vérifier un serveur en cinq minutes, et la mesure recommandée par les éditeurs pour les serveurs que vous ne pouvez pas encore corriger.
En 30 secondes
- CVE-2026-98432 est une situation de concurrence (race condition) dans la poignée de main TCP IPv4 du noyau Linux, qui mène à une utilisation de mémoire libérée (use-after-free). Elle existe dans tous les noyaux depuis la version 4.4 jusqu’au correctif. L’IPv6 n’est pas touché par le problème principal.
- Corrigé : RHEL 8/9/10, AlmaLinux, Rocky Linux, Debian, Oracle Linux, SUSE (certaines versions), les noyaux 7.0 de Proxmox et les noyaux récents d’Amazon Linux 2023. Pas encore : Ubuntu, Amazon Linux 2, le noyau temps réel de RHEL 9 et OpenShift. Un correctif ne compte qu’après un redémarrage.
- Mesure d’atténuation : Red Hat et AlmaLinux publient la même mesure temporaire : rejeter les paquets TCP IPv4 entrants qui contiennent des options IP. Désactiver le TCP multichemin (MPTCP) ferme le chemin utilisé par l’exploit d’Anthropic, mais ne suffit pas à lui seul.
Sommaire : État des correctifs CVE-2026-98432 par distribution · Ce qu’est vraiment la faille · Pourquoi les scores divergent · Le rôle d’un service à l’écoute en TCP multichemin · Qui doit s’inquiéter en premier · Vérifier un serveur en cinq minutes · Atténuer CVE-2026-98432 en attendant · Ce qu’il ne faut pas faire · Votre semaine, dans l’ordre · Sept questions, sept réponses franches
Selon ce que les éditeurs ont publié entre le 29 octobre et le 2 novembre 2026. Installez le noyau corrigé, redémarrez, puis vérifiez que uname -r affiche la nouvelle version :
Distribution | État | Paquet corrigé ou avis |
|---|---|---|
Ubuntu 16.04 à 26.10, noyaux infonuagiques compris | Non corrigé — vulnérable, correctif en cours | Aucun USN pour l’instant |
RHEL 8, 9, 10 | Corrigé (1er novembre) | RHSA-2026:93414 / 93412 / 93413 · kernel-4.18.0-553.182.1.el8_10 / 5.14.0-687.64.1.el9_8 / 6.12.0-211.72.1.el10_2 |
Noyau temps réel de RHEL 9, OpenShift | Non corrigé au 1er novembre | Bulletin RHSB-2026-016 |
AlmaLinux 8, 9, 10 | Corrigé (2 novembre) | ALSA-2026:93414 · mêmes versions de noyau que RHEL |
Rocky Linux 8, 9, 10 | Corrigé | kernel-4.18.0-553.180.1.el8_10.0.1 / 5.14.0-687.61.1.el9_8.0.1 / 6.12.0-211.69.1.el10_2.0.1 |
Debian 13 (trixie) | Corrigé | linux 6.12.113-1 (DSA-6568-1) |
Debian 12 (bookworm) | Corrigé | linux 6.1.190-1 (DLA-4841-1) · linux-6.12 6.12.113-1~deb12u1 (DLA-4850-1) |
Proxmox VE et Proxmox Backup Server | Corrigé dans le noyau 7.0; 6.8, 6.14 et 6.17 non corrigés au 30 octobre | proxmox-kernel 7.0.14-25-pve ou plus récent |
Amazon Linux 2023 (AWS), kernel6.18 / kernel6.12 | Corrigé | ALAS2023-2026-3251 / ALAS2023-2026-3335 |
Amazon Linux 2 et le paquet kernel d’Amazon Linux 2023 | En attente | Aucun |
Oracle Linux 7 à 10, noyau UEK | Corrigé | ELSA-2026-500397 / 500398 / 500399 |
SUSE Linux Micro 6.2, openSUSE Leap 16.0 | Corrigé | kernel-default 6.12.0-160000.40.1 ou plus récent |
SLES 15 SP4 à SP7, SLES 16.0 | En test ou en cours | Aucun |
RHEL 7 | Non touché | Inutile |
Toutes les versions prises en charge, de 16.04 à 26.10, sont listées comme vulnérables avec un correctif en cours, noyaux infonuagiques, FIPS et temps réel compris. Canonical n’a donné aucune date et aucun avis de sécurité Ubuntu (USN) n’a encore paru. D’ici là, appliquez la mesure d’atténuation ci-dessous, laissez unattended-upgrades actif pour les mises à jour de sécurité, et planifiez le redémarrage pour le jour où l’USN sortira. Pour savoir si le paquet de votre noyau mentionne le correctif, lisez le journal des modifications de linux-modules-…, comme dans la vérification de cinq minutes.
Red Hat a publié des noyaux corrigés pour RHEL 8, 9 et 10 le 1er novembre. AlmaLinux a versé les mêmes versions dans ses dépôts de production le 2 novembre, et Rocky Linux a publié ses propres noyaux corrigés en production. Lancez dnf upgrade, redémarrez, et comparez uname -r au tableau. Le noyau temps réel de RHEL 9 et OpenShift attendaient encore au 1er novembre : appliquez-y la mesure d’atténuation.
Le noyau de Proxmox est construit à partir des sources du noyau d’Ubuntu, mais Proxmox a confirmé sur son forum de soutien que son noyau 7.0 contient le correctif à partir de 7.0.14-25-pve, dans les dépôts enterprise, no-subscription et test. Les séries plus anciennes 6.8, 6.14 et 6.17 n’avaient aucune version corrigée au 30 octobre. Utilisez apt full-upgrade, pas un simple apt upgrade, puis redémarrez :
# 7.0.14-25-pve or newer has the fix
uname -r
pveversion -v | grep -i kernel
# A pinned kernel keeps booting the old one
proxmox-boot-tool kernel listLes conteneurs LXC partagent le noyau de l’hôte : ils sont couverts dès que l’hôte tourne sur un noyau corrigé. Les machines virtuelles ont leur propre noyau et ont besoin du correctif de leur propre distribution. Dans une grappe, migrez les invités et redémarrez les nœuds un à un.
Les paquets kernel6.18 et kernel6.12 d’Amazon Linux 2023 sont corrigés. Amazon Linux 2 et le paquet kernel par défaut d’Amazon Linux 2023 étaient encore en attente. Les instances EC2 sous Ubuntu, RHEL ou Debian suivent l’état de ces éditeurs, pas celui d’Amazon.
Le correctif se trouve dans Linux 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 et 7.3. L’équipe CVE du noyau recommande de passer au plus récent noyau stable et ne prend pas en charge l’application isolée du seul correctif.
Chaque connexion TCP commence par une poignée de main : le client envoie une demande de connexion (un SYN), le serveur répond, le client confirme. Un paquet IPv4 peut transporter des éléments facultatifs dans son en-tête, appelés options IP. Quand une demande de connexion en contient, le noyau en garde une copie pour s’en servir dans sa réponse.
Le bogue tient à ce qui arrive à cette copie. Quand la connexion est établie, le noyau remet les options conservées au nouveau socket sans les dupliquer. Si ce socket est détruit pendant qu’un autre processeur utilise encore ces mêmes options pour répondre à une demande de connexion renvoyée, le noyau lit de la mémoire déjà libérée. C’est une utilisation de mémoire libérée et, dans le code réseau du noyau, cela peut entraîner une fuite de mémoire, une corruption de mémoire ou un plantage.
Un second chemin semblable existe quand le noyau migre des connexions en attente d’un socket d’écoute à un autre (net.ipv4.tcp_migrate_req=1, désactivé par défaut). L’IPv6 n’a pas le problème principal, car le noyau copie les options des connexions IPv6.
La chronologie : le bogue est apparu dans Linux 4.4. Les développeurs du noyau ont appliqué le correctif le 5 octobre 2026, la CVE a été annoncée le 15 octobre, et le score de 9,8 a été ajouté le 24 octobre. Anthropic a décrit son exploit le 27 octobre, Red Hat a relevé son évaluation à « critique » le 30 octobre et publié ses correctifs le 1er novembre.
Vous verrez des chiffres différents pour la même CVE, et cela compte pour la priorité que lui donne votre éditeur :
Qui | Score | Pourquoi |
|---|---|---|
Équipe CVE du noyau Linux (CNA) | 9,8 Critique | Complexité d’attaque jugée faible : les deux côtés de la course sont provoqués par l’attaquant. |
Red Hat | 9,8 Critique (depuis le 30 octobre) | Relevé depuis Modéré 5,9 : aucun privilège, aucune interaction, du trafic TCP IPv4 ordinaire. |
Oracle, SUSE | 8,1 Important | Même vecteur que l’équipe du noyau, sauf la complexité d’attaque, jugée élevée. |
Amazon | 7,0 Important | — |
Le 9,8 suppose qu’un attaquant envoie une demande de connexion contenant les options IPv4 Record Route ou Timestamp, puis la renvoie pour gagner la course. Le texte d’Anthropic ajoute le détail qui change le calcul du risque : une course perdue fait seulement échouer cette tentative de connexion, sans faire planter le serveur, si bien qu’un attaquant peut réessayer sans fin. Lors de son test, obtenir une adresse du noyau a pris 48 minutes, et l’exécution de commandes cinq minutes de plus. Ces affirmations n’ont pas été vérifiées de façon indépendante, mais pour un serveur exposé à Internet, nous traitons cette faille comme urgente, peu importe le chiffre affiché par votre éditeur.
Le MPTCP permet à une seule connexion d’emprunter plusieurs chemins réseau à la fois. Sous Linux, une application doit le demander en ouvrant un socket. L’exploit root d’Anthropic, qui selon l’entreprise a été écrit par son modèle d’IA Claude après une première consigne, visait des serveurs ayant un service à l’écoute en MPTCP. Ni la fiche CVE ni le correctif du noyau ne mentionnent le MPTCP : ce lien vient uniquement du texte d’Anthropic.
Deux détails en font plus qu’une note de bas de page. D’abord, depuis Go 1.24, les programmes Go demandent le MPTCP par défaut pour les sockets sur lesquels ils écoutent : un serveur peut donc avoir des services MPTCP que personne n’a configurés exprès. Ensuite, l’équipe de sécurité de Go précise que le bogue sous-jacent n’est pas propre au MPTCP, et Red Hat décrit la surface touchée comme tout système qui accepte des connexions TCP IPv4 entrantes. Aucun service MPTCP veut dire que le chemin d’exploitation publié est fermé, pas que vous êtes protégés.
Aucun outil supplémentaire. Lancez ces commandes sur chaque serveur, pas sur votre portable :
# Running kernel; on Debian, uname -v shows the package version
uname -r
uname -v
# Ubuntu: does the running kernel's changelog mention the fix?
apt changelog linux-modules-$(uname -r) 2>/dev/null \
| grep -c CVE-2026-98432
# RHEL, Rocky, AlmaLinux, Oracle Linux
rpm -q --changelog kernel-$(uname -r) | grep -c CVE-2026-98432
# Newest installed kernel (reboot pending if newer than uname -r)
ls -1 /boot/vmlinuz-* | sort -V | tail -1
# MPTCP and the secondary migration path
sysctl net.mptcp.enabled net.ipv4.tcp_migrate_req
# Services listening with MPTCP
ss -lnpMuname -r au tableau ci-dessus. Les noyaux des distributions gardent leur version de base et rétroportent les correctifs : pour eux, ce sont le suivi de l’éditeur et le journal des modifications du paquet qui comptent.linux-modules-…. Celui de linux-image-… provient du paquet signé et ne liste pas les CVE : y chercher ne trouve donc jamais rien. Un résultat de 0 signifie que le paquet du noyau en cours d’exécution ne mentionne pas le correctif./boot est plus récent que uname -r, un correctif est peut-être installé sans être actif.net.mptcp.enabled = 1 et au moins une ligne dans ss -lnpM signifient que le chemin d’exploitation publié est ouvert dans cet espace de noms réseau. tcp_migrate_req doit valoir 0.Red Hat et AlmaLinux publient la même mesure provisoire, et en disent la même chose : elle réduit l’exposition, elle ne remplace pas le noyau corrigé, et il faut la tester d’abord.
Le bogue ne peut être déclenché que par une demande de connexion contenant des options IPv4. Le code source du noyau explique pourquoi : les options libérées trop tôt ne sont conservées que si le SYN entrant en contient réellement. Les options TCP ordinaires (mise à l’échelle de la fenêtre, horodatage, SACK) se trouvent dans l’en-tête TCP, pas dans l’en-tête IP : le trafic normal n’est donc pas touché. Le filtre vérifie la longueur de l’en-tête IPv4 : tout ce qui dépasse les 20 octets de base contient des options.
Nous reprenons la forme d’AlmaLinux parce qu’elle s’accroche au point prerouting : elle couvre donc aussi le trafic redirigé vers des conteneurs et des machines virtuelles. Le bulletin de Red Hat propose une règle équivalente sur le point input, qui ne voit pas le trafic redirigé. Enregistrez ceci sous /etc/cve-2026-98432.nft :
add table ip cve_2026_98432
delete table ip cve_2026_98432
table ip cve_2026_98432 {
chain prerouting {
type filter hook prerouting priority -300; policy accept;
meta l4proto tcp ip hdrlength > 5 counter drop
}
}Les deux premières lignes permettent de charger le fichier plusieurs fois sans erreur. Vérifiez-le, chargez-le, puis surveillez le compteur :
# Dry run first, then load and check the counter (should stay 0)
nft --check -f /etc/cve-2026-98432.nft
nft -f /etc/cve-2026-98432.nft
nft list table ip cve_2026_98432Une règle chargée à la main disparaît au redémarrage. Pour la garder, enregistrez ceci sous /etc/systemd/system/cve-2026-98432-stopgap.service et activez-le. Si vous gérez déjà vos règles avec nftables.service, ajoutez plutôt la table à cette configuration, car son rechargement vide les tables qu’elle ne connaît pas.
[Unit]
Description=CVE-2026-98432 stopgap: drop IPv4 TCP with IP options
After=network-pre.target
Before=network.target docker.service
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/sbin/nft -f /etc/cve-2026-98432.nft
ExecStop=/usr/sbin/nft delete table ip cve_2026_98432
[Install]
WantedBy=multi-user.targetsystemctl daemon-reload
systemctl enable --now cve-2026-98432-stopgapSur les hôtes qui n’utilisent qu’iptables, voici la règle équivalente dans la table raw :
iptables -t raw -I PREROUTING -p tcp \
-m u32 --u32 "0>>24&0x0F=6:15" -j DROPConnaissez ses limites avant de vous y fier. Elle ne couvre que l’IPv4, là où se trouve le bogue principal. Elle casse les réseaux qui dépendent des étiquettes de sécurité CIPSO/NetLabel, qui utilisent des options IP. Et le trafic entre conteneurs d’un même hôte peut ne jamais passer par le point prerouting de l’hôte, et donc contourner le filtre.
Cela ferme le chemin utilisé par l’exploit d’Anthropic, sans redémarrage, et le fichier conserve le réglage après un redémarrage :
echo 'net.mptcp.enabled=0' > /etc/sysctl.d/90-disable-mptcp.conf
sysctl -w net.mptcp.enabled=0
# Anything still listed was opened earlier: restart that service
ss -lnpMLes services qui écoutaient déjà en MPTCP le gardent jusqu’à leur redémarrage. Les programmes Go reviennent d’eux-mêmes au TCP ordinaire quand le MPTCP est désactivé. Attention : ce réglage appartient à un espace de noms réseau. Les commandes ci-dessus couvrent l’hôte, pas vos conteneurs ni vos pods. Vérifiez dans chacun, par exemple avec nsenter -t <pid> -n ss -lnM, ou réglez-le par votre moteur de conteneurs ou la configuration sysctl de vos pods. Pour les services Go, vous pouvez aussi définir GODEBUG=multipathtcp=0 dans leur environnement, mais l’équipe Go qualifie ces réglages par programme de fragiles : un seul service oublié laisse le serveur exposé, et le code qui appelle SetMultipathTCP passe outre.
À elle seule, l’étape 2 ne suffit pas, puisque le bogue ne se limite pas au MPTCP. Utilisez-la avec l’étape 1, pas à sa place.
Une suggestion publiée sur la liste oss-security ajoute le paramètre de démarrage init_on_free=1, qui remet à zéro la mémoire libérée. Il ne corrige pas le bogue, mais il réduit ce qu’un attaquant peut lire par son entremise. Il exige un redémarrage et coûte, selon les chiffres souvent cités, de 1 à 5 % sur les charges qui libèrent beaucoup de mémoire : mesurez-le chez vous.
Une fois que uname -r affiche un noyau corrigé :
# or: nft delete table ip cve_2026_98432
systemctl disable --now cve-2026-98432-stopgap
rm /etc/sysctl.d/90-disable-mptcp.conf
sysctl -w net.mptcp.enabled=1uname -r.uname -r, puis retirez la mesure d’atténuation.Pas encore. Au 2 novembre, Ubuntu liste toutes ses versions prises en charge comme vulnérables, correctif en cours, et n’a publié aucun avis de sécurité. Appliquez la mesure d’atténuation ci-dessus et surveillez la page CVE d’Ubuntu.
En amont : 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 et 7.3. Les noyaux des distributions ont leurs propres numéros de version : fiez-vous au tableau ci-dessus ou à l’avis de votre éditeur plutôt qu’au numéro amont.
Pas par le bogue principal : le noyau copie les options des connexions IPv6. Le correctif mentionne un problème de migration IPv6 apparenté, qui ne concerne que l’étiquetage CALIPSO, et annonce un correctif distinct.
Ni les avis des éditeurs, ni la fiche CVE, ni le texte d’Anthropic ne signalent d’attaques, et au 29 octobre la CVE ne figurait pas au catalogue des vulnérabilités exploitées de la CISA. Anthropic n’a pas publié son code d’exploitation. Cela donne du temps, pas une protection : la méthode est désormais décrite publiquement, et une course perdue ne laisse guère de trace au-delà d’une poignée de main échouée.
Pas forcément. Les programmes Go l’activent par défaut pour leurs services depuis Go 1.24 : vérifiez avec ss -lnpM plutôt que de le supposer. Et l’équipe de sécurité de Go précise que des serveurs sans service MPTCP pourraient être vulnérables à des attaques semblables.
Non. Les conteneurs utilisent le noyau de l’hôte. Corrigez l’hôte et redémarrez-le.
Oui, à moins que votre éditeur publie un correctif à chaud. Le correctif est dans le noyau, et le noyau en cours d’exécution ne change qu’au démarrage sur le nouveau.
S’il ne fallait retenir qu’une chose : le correctif de CVE-2026-98432, c’est un noyau sur lequel vous avez redémarré. Pour la plupart des distributions, ce noyau existe déjà : le travail consiste à planifier les redémarrages. Pour Ubuntu, il n’existe pas encore : placez le filtre devant ces serveurs et tenez la liste de ce qu’il faudra redémarrer le jour où la mise à jour arrivera.
Si vous préférez ne pas parcourir la liste seuls, notre évaluation gratuite passera vos serveurs en revue avec vous, et la liste vous reste dans tous les cas. Ce travail fait partie de la cybersécurité pour les entreprises en croissance.
Encadré de confiance — sources et révision
- Annonce CVE du noyau Linux (15 octobre 2026) : description du correctif, apparition dans 4.4, versions stables corrigées, consigne contre l’application isolée.
- Red Hat : bulletin RHSB-2026-016 et page CVE (critique, 9,8; filtre nftables au point input), noyaux corrigés RHSA-2026:93414 (RHEL 8), RHSA-2026:93412 (RHEL 9), RHSA-2026:93413 (RHEL 10), 1er novembre 2026.
- AlmaLinux (mis à jour le 2 novembre : correctif en production, ALSA-2026:93414, filtre nftables au point prerouting) · annonce officielle de Rocky Linux de noyaux corrigés en production · forum de soutien Proxmox (personnel de Proxmox, 30 octobre : correctif dans 7.0.14-25-pve et plus récent).
- Page CVE d’Ubuntu (mise à jour le 30 octobre) et Security Boulevard (2 novembre : correctif Ubuntu toujours en cours au 1er novembre) · suivi de sécurité Debian.
- The Hacker News (29 octobre, mis à jour le 30) et note de recherche de la Cloud Security Alliance (1er novembre) : état chez Oracle, SUSE et Amazon, consignes de l’équipe de sécurité de Go, limites du filtre, réglage MPTCP propre à chaque espace de noms réseau.
- Anthropic, Frontier Red Team (27 octobre 2026) : exploit visant des serveurs ayant un service MPTCP; une course perdue fait seulement échouer une poignée de main; 48 + 5 minutes lors de son test.
- oss-security (31 octobre 2026) :
init_on_free=1comme renforcement supplémentaire. Code source Linuxtcp_v4_save_options(): options conservées seulement si le SYN en contient. Les deux règles nftables ci-dessus passentnft --check.- Révisé le 2 novembre 2026. Par Amen Security, une équipe de Winnipeg spécialisée en TI gérées et en développement Web et applications pour les PME du Canada et des États-Unis. Ce texte ne revendique aucun service, prix, partenariat ou certification au-delà de ce que le site en ligne démontre.
Votre commentaire sera publié après examen par notre équipe.
Continuer la lecture
Qu’est-ce qu’une vulnérabilité CVE ? C’est le numéro public d’une faille logicielle, le même dans tous les pays. Voici la signification CVE, comment lire un identifiant CVE, et ce qu’un score CVSS ne décide pas.
Node2Shell (CVE-2026-111497) : une faille Brotli dans Node.js, Python, Bun et Envoy. Versions corrigées, correctif Python discret, et la chasse à chaque copie.
Deux failles critiques de PHP (CVE-2026-109618 et CVE-2026-109619) menacent les sites non corrigés. Vérifiez la version, l'hébergeur, puis corrigez.