# CVE-2026-98432 : état des correctifs de la faille TCP du noyau Linux pour Ubuntu, RHEL, Debian, AWS et Proxmox

> Amen Security Team · 2026-11-02T20:53:41.052Z · security · cybersecurity · linux · cve · kernel · patching

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

État des correctifs CVE-2026-98432 par distribution

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

Ubuntu

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.

RHEL, Rocky Linux et AlmaLinux

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.

Proxmox VE et Proxmox Backup Server

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 list

Les 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.

AWS et Amazon Linux

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.

Si vous compilez votre propre noyau

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.

Ce qu’est vraiment la faille

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.

Pourquoi les scores divergent

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 rôle d’un service à l’écoute en TCP multichemin

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.

Qui doit s’inquiéter en premier

- Les serveurs Ubuntu exposés à Internet. Aucun noyau corrigé n’existe encore : la mesure d’atténuation est votre seule protection jusqu’à la sortie de l’USN.
- Les serveurs corrigés mais pas redémarrés. Sur RHEL, Rocky, AlmaLinux, Debian et Proxmox, le correctif est sorti, mais l’ancien noyau tourne jusqu’au redémarrage.
- Les serveurs qui font tourner des services Go. Mandataires inverses, passerelles d’API, agents, composants Kubernetes et outils internes écrits en Go peuvent écouter en MPTCP sans que personne l’ait choisi.
- Les hôtes dont des ports TCP sont ouverts directement sur Internet. Si le serveur n’est joignable qu’à travers un mandataire ou un répartiteur de charge qui termine la connexion TCP, les demandes de connexion que voit votre noyau viennent de ce mandataire, pas de l’attaquant. Cela n’aide que si l’adresse IP du serveur lui-même n’est pas aussi joignable directement.
- Les hôtes de conteneurs. Les conteneurs partagent le noyau de l’hôte : reconstruire les images ne change rien à cette CVE. Ils ont aussi leurs propres espaces de noms réseau, ce qui compte pour les deux volets de la mesure d’atténuation ci-dessous.

Vérifier un serveur en cinq minutes

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 -lnpM

- Version du noyau : comparez uname -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.
- Journal des modifications : sous Ubuntu, lisez celui de 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.
- Redémarrage en attente : si le noyau le plus récent dans /boot est plus récent que uname -r, un correctif est peut-être installé sans être actif.
- MPTCP : 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.

Atténuer CVE-2026-98432 en attendant

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.

Étape 1 : rejeter les paquets TCP IPv4 entrants qui contiennent des options IP

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_98432

Une 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.target

systemctl daemon-reload
systemctl enable --now cve-2026-98432-stopgap

Sur 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 DROP

Connaissez 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.

Étape 2 : désactiver le TCP multichemin

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 -lnpM

Les 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.

Renforcement facultatif : init_on_free=1

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.

La retirer après le correctif

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=1

Ce qu’il ne faut pas faire

- Ne pas confondre « pas de MPTCP » et « corrigé ». Un serveur qui répond en TCP ordinaire a fermé un chemin d’exploitation. Le bogue est toujours dans son noyau.
- Ne pas s’arrêter au gestionnaire de paquets. Un noyau installé mais pas démarré ne protège rien. Sous Proxmox, vérifiez aussi qu’aucun ancien noyau n’est épinglé.
- Ne pas corriger les conteneurs et s’en tenir là. Ils tournent sur le noyau de l’hôte.
- Ne pas compter sur un filtre au point input sur un hôte de conteneurs. Le trafic redirigé n’y passe jamais : utilisez prerouting.
- Ne pas retirer la mesure d’atténuation trop tôt. Attendez que le noyau corrigé soit celui qui tourne.
- Ne pas greffer le correctif seul sur un vieux noyau. L’équipe du noyau ne le prend pas en charge : passez à une version stable corrigée ou au paquet de votre éditeur.

Votre semaine, dans l’ordre

- Aujourd’hui : dressez la liste de chaque serveur Linux exposé à Internet, nœud Proxmox et machine virtuelle, avec sa distribution et son uname -r.
- Aujourd’hui : là où un correctif existe (RHEL, Rocky, AlmaLinux, Debian, Oracle Linux, SUSE, Proxmox 7.0, noyaux récents d’Amazon Linux 2023), installez-le et planifiez le redémarrage.
- Aujourd’hui : sur Ubuntu et tout ce qui attend encore, chargez le filtre des options IP, vérifiez que chaque service publié répond toujours, et rendez-le permanent.
- Cette semaine : désactivez le MPTCP là où vous n’en avez pas besoin, y compris dans les conteneurs, et redémarrez les services qui l’utilisaient.
- Quand Ubuntu publiera : installez, redémarrez, vérifiez uname -r, puis retirez la mesure d’atténuation.

Sept questions, sept réponses franches

Existe-t-il un correctif CVE-2026-98432 pour Ubuntu?

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.

Quelles versions du noyau corrigent CVE-2026-98432?

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.

L’IPv6 est-il touché?

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.

La faille est-elle exploitée en ce moment?

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.

Nous n’utilisons pas le MPTCP. Sommes-nous protégés?

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.

Des images de conteneurs à jour règlent-elles le problème?

Non. Les conteneurs utilisent le noyau de l’hôte. Corrigez l’hôte et redémarrez-le.

Faut-il vraiment redémarrer?

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.

Pour aller plus loin

- [Qu’est-ce qu’une vulnérabilité CVE ?](https://amensecurity.ca/fr/blog/what-is-a-cve) — comment s’articulent numéros CVE, scores et évaluations des éditeurs, et pourquoi ils divergent.
- [Node2Shell (CVE-2026-111497)](https://amensecurity.ca/fr/blog/node2shell-nodejs-brotli-rce-october-2026) — la faille d’octobre cachée dans chaque copie intégrée d’une bibliothèque.
- [PHP2Shell : la vérification de 15 minutes pour votre site Web](https://amensecurity.ca/fr/blog/php2shell-critical-php-vulnerability-canada-2026) — l’histoire du même mois côté Web, et sa vérification rapide.

Corriger là où c’est possible, filtrer ailleurs

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](https://amensecurity.ca/fr/contact?tab=consult&utm_source=blog&utm_medium=site&utm_campaign=linux-kernel-tcp-flaw-cve-2026-98432) 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](https://amensecurity.ca/fr/services/cybersecurity).

Encadré de confiance — sources et révision
- [Annonce CVE du noyau Linux](https://lists.openwall.net/linux-cve-announce/2026/10/15/1) (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](https://access.redhat.com/security/vulnerabilities/RHSB-2026-016) et [page CVE](https://access.redhat.com/security/cve/CVE-2026-98432) (critique, 9,8; filtre nftables au point input), noyaux corrigés [RHSA-2026:93414](https://access.redhat.com/errata/RHSA-2026:93414) (RHEL 8), [RHSA-2026:93412](https://access.redhat.com/errata/RHSA-2026:93412) (RHEL 9), [RHSA-2026:93413](https://access.redhat.com/errata/RHSA-2026:93413) (RHEL 10), 1er novembre 2026.
- [AlmaLinux](https://almalinux.org/blog/2026-10-30-cve-2026-98432/) (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](https://forum.proxmox.com/threads/cve-2026-98432-in-proxmox-ve.187339/) (personnel de Proxmox, 30 octobre : correctif dans 7.0.14-25-pve et plus récent).
- [Page CVE d’Ubuntu](https://ubuntu.com/security/CVE-2026-98432) (mise à jour le 30 octobre) et [Security Boulevard](https://securityboulevard.com/2026/11/linux-kernel-tcp-flaw-rated-9-8-gets-a-remote-root-exploit-from-an-ai-model/) (2 novembre : correctif Ubuntu toujours en cours au 1er novembre) · [suivi de sécurité Debian](https://security-tracker.debian.org/tracker/CVE-2026-98432).
- [The Hacker News](https://thehackernews.com/2026/10/linux-kernel-tcp-flaw-with-98-cvss.html) (29 octobre, mis à jour le 30) et [note de recherche de la Cloud Security Alliance](https://labs.cloudsecurityalliance.org/research/csa-research-note-linux-tcp-mptcp-cve-2026-98432-20261101-cs/) (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](https://www.anthropic.com/research/discovering-vulnerabilities-with-claude) (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](https://openwall.com/lists/oss-security/2026/10/31/5) (31 octobre 2026) : init_on_free=1 comme renforcement supplémentaire. Code source Linux tcp_v4_save_options() : options conservées seulement si le SYN en contient. Les deux règles nftables ci-dessus passent nft --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.

## Sujet : Cybersécurité et conformité
- [Guide principal](https://amensecurity.ca/fr/services/cybersecurity.md)
- [TI gérées ou dépannage à la demande : comparaison côte à côte](https://amensecurity.ca/fr/guides/msp-vs-break-fix.md)

---
Source page: https://amensecurity.ca/fr/blog/linux-kernel-tcp-flaw-cve-2026-98432
Markdown version for AI agents · Amen Security
Email: info@amensecurity.ca
Phone: +1 (204) 514-3536