CVE-2026-98432 : la faille TCP du noyau Linux dont une IA a tiré un exploit root à distance

Une faille réseau du noyau, puis un exploit écrit par une IA

Le 15 octobre 2026, l'équipe CVE du noyau Linux a publié CVE-2026-98432. Il s'agit d'un use-after-free dans le traitement des connexions TCP entrantes en IPv4, noté 9,8 sur 10 : exploitable par le réseau, sans authentification, sans action de l'utilisateur.

Le code en cause date de Linux 4.4, sorti en janvier 2016. Presque tous les noyaux en production sont donc concernés, des branches longue durée de RHEL ou de Debian jusqu'aux 7.x récents.

Pendant deux semaines, on l'a traitée comme une CVE critique de plus. Le 27 octobre, Anthropic a publié un compte rendu qui change la lecture du risque : un modèle Claude de recherche, non commercialisé, a écrit un exploit qui obtient un shell root sur un serveur distant en 53 minutes environ. Il lui a fallu 48 minutes pour faire fuir un pointeur du noyau, puis cinq de plus pour exécuter des commandes.

Les faits

Les éditeurs ne s'accordent pas sur la gravité :

• 9,8 pour le CNA du noyau, qui y voit une exécution de code à distance ;
• 5,9 sur la première version de la page de Red Hat, qui y voyait un déni de service derrière une course difficile à gagner, avant de remonter à 9,8 et « Critical » ;
• 8,1 chez SUSE, qui juge la complexité d'attaque élevée (AC:H).

L'argument de la course « difficile à gagner » tient mal, on y revient plus bas.

Un point à retenir dès maintenant : le bug se trouve dans le TCP IPv4 ordinaire. MPTCP n'apparaît que dans l'exploit root publié. Red Hat l'écrit clairement, RHEL, « qui désactive MPTCP dans sa configuration par défaut, reste vulnérable ».

Correctifs par distribution (5 novembre 2026)

Ce tableau évolue tous les jours. Vérifiez le suivi de votre éditeur avant d'agir.

Et gardez en tête qu'un noyau corrigé ne protège qu'après redémarrage.

Ubuntu, toujours en attente

• Tous les noyaux sont marqués « en cours », variantes cloud comprises (linux-aws, linux-azure, linux-gcp).
• La priorité est passée à « Critical » le 4 novembre, sans paquet corrigé pour autant.
• Si vous exposez des services sur Ubuntu, le filtre réseau décrit plus bas est aujourd'hui votre principale protection.

Proxmox VE, corrigé par la bande

Le noyau de Proxmox est construit sur celui d'Ubuntu. Le correctif est arrivé avec les sources Ubuntu 7.0.0-43, et Proxmox l'a livré dans 7.0.14-25-pve puis -26, désormais aussi sur le dépôt enterprise.

Un développeur Proxmox a confirmé sur le forum que le commit correctif y figure. Le suivi de sécurité d'Ubuntu, lui, n'a pas encore rattrapé son propre arbre de sources, d'où le décalage entre les deux.

Pour Proxmox VE 8, nous n'avons trouvé aucune confirmation.

Comment fonctionne la faille

Pas besoin de lire le C du noyau pour comprendre le principe. Voici le déroulé normal d'une connexion :

1. Un client ouvre une connexion TCP, et son SYN porte des options IPv4.
2. Le noyau conserve ces options sur le socket de requête en attente, pour les renvoyer dans le SYN-ACK.
3. En fin de poignée de main, tcp_v4_syn_recv_sock() crée le socket définitif et lui transmet le tampon d'options par pointeur, sans le copier.

C'est correct tant que personne d'autre ne lit l'ancien tampon. Or depuis une modification de 2015, les requêtes SYN-RECV peuvent être traitées sans le verrou de l'écouteur.

Un second processeur peut donc traiter, au même moment, un SYN retransmis pour la même requête. Il lit les options sous un simple verrou de lecture RCU pour construire son propre SYN-ACK. Si le socket enfant est détruit pendant ce temps, et ses options libérées par kfree(), ce processeur lit une mémoire qui appartient déjà à autre chose.

Un second chemin mène au même résultat : la migration des sockets de requête (net.ipv4.tcp_migrate_req=1, ou un programme BPF reuseport). Ce réglage est désactivé par défaut. Pour la plupart des serveurs, c'est donc le SYN retransmis qui compte.

Le correctif est court. Dans deux destructeurs, kfree() devient kfree_rcu(), qui attend la fin d'un délai de grâce RCU avant de libérer la mémoire. Les autres chemins qui manipulent ces options procédaient déjà ainsi.

IPv6 échappe au problème principal, car tcp_v6_syn_recv_sock() copie les options au lieu de les transmettre.

L'exploit d'Anthropic : ce qui est démontré

Le 27 octobre, Anthropic a indiqué qu'un modèle de recherche Claude, non publié, avait écrit un exploit distant complet pour ce bug, « après une invite initiale ».

Nous prenons cette annonce avec la prudence habituelle, puisque ni le code ni la configuration de test ne sont publiés. Deux éléments la rendent tout de même crédible :

• la chaîne décrite est cohérente avec le commit correctif ;
• le Reported-by de ce commit désigne un chercheur d'Anthropic, qui connaissait donc ce code bien avant la publication.

53 minutes d'un côté, 43 jours de l'autre

Le Data Breach Investigations Report 2026 de Verizon donne deux repères utiles pour situer ce chiffre :

• le délai médian de correction d'une vulnérabilité du catalogue KEV de la CISA atteint 43 jours, contre 32 un an plus tôt ;
• 31 % des accès initiaux commencent désormais par l'exploitation d'une vulnérabilité.

Moins d'une heure de calcul pour obtenir root, six semaines de délai médian pour corriger. Accélérer le correctif manuel ne suffira pas à combler cet écart.

Qui est exposé ?

Le numéro de noyau compte moins qu'une question simple : exposez-vous un service TCP en IPv4 sur un noyau non corrigé ?

C'est le cas de presque tous les serveurs. Le tri se fait donc sur l'exposition :

• Serveur Linux joignable depuis Internet (web, API, SSH, messagerie, répartiteur de charge) : exposé. C'est le cas le plus courant, et le plus urgent.
• Services Go compilés avec Go 1.24 ou plus récent : à examiner en priorité. Depuis Go 1.24, la bibliothèque standard active Multipath TCP par défaut sur les sockets en écoute sous Linux. C'est précisément la configuration visée par l'exploit d'Anthropic, et peu d'équipes l'ont choisie en connaissance de cause.
• RHEL et ses dérivés, où MPTCP est désactivé : l'exploit publié ne s'applique pas tel quel, mais la faille est bien présente. Red Hat le précise, le correctif reste critique.
• IPv6 : le bug principal ne touche que l'IPv4. Un serveur double pile répond toujours en IPv4 et reste donc exposé.

Et dans le cloud ?

C'est souvent la première question en réunion. Le bulletin 2026-160 d'AWS illustre bien le partage des responsabilités :

• AWS a corrigé ses propres services frontaux (ALB, NLB TLS, CloudFront, API Gateway, WAF) ;
• Lambda est hors périmètre ;
• des noyaux corrigés existent pour Amazon Linux 2 et 2023 ;
• les instances EC2 et Lightsail que vous gérez restent à votre charge : mise à jour du noyau puis redémarrage, ce qu'AWS appelle « la seule remédiation complète ».

GameLift Streams et les environnements Cloud9 sous Ubuntu attendent, comme tout le monde, le correctif de Canonical.

Vérifier ses serveurs sans rien casser

N'essayez pas de reproduire la faille sur vos propres machines. La course peut faire tomber l'hôte, et il n'existe pas de charge inoffensive à envoyer.

La vérification se fait sur l'hôte lui-même, à partir de la version et de la configuration.

1. Le noyau réellement démarré

uname -r

2. Les écouteurs Multipath TCP

C'est la configuration du seul exploit root publié. Elle est souvent active sans que personne l'ait décidé.

sysctl net.mptcp.enabled       # 1 = création de sockets MPTCP possible
ss -lnMp                        # processus qui tiennent des écouteurs MPTCP

Si ss -lnMp affiche des écouteurs inattendus, ce sont vos cibles prioritaires.

Pour les binaires Go, deux options sans toucher au noyau :

• GODEBUG=multipathtcp=0 dans l'environnement du service ;
• une ligne godebug multipathtcp=0 dans le go.mod du module principal, puis une recompilation.

L'équipe sécurité de Go parle elle-même d'« une atténuation fragile ». Un seul écouteur oublié suffit à rouvrir la porte, et rien ne garantit que tout exploit viable passe par MPTCP. Sa première recommandation reste le noyau corrigé. C'est aussi la nôtre.

3. Depuis l'extérieur, peu de choses

Un scan externe ne peut pas dire si un hôte est vulnérable à CVE-2026-98432, car la version du noyau n'est pas visible à distance.

On peut parfois savoir si un port accepte MPTCP, en proposant l'option MP_CAPABLE dans un SYN et en regardant si elle revient dans le SYN-ACK. Cela renseigne sur le protocole, pas sur le niveau de correctif du noyau.

L'extérieur sert à autre chose : savoir quels hôtes exposent un service TCP, et repérer ceux qui apparaissent.

Corriger, et tenir en attendant

Les mesures, de la plus efficace à la moins efficace :

1. Installer le noyau corrigé et redémarrer. C'est la seule correction complète. Sur les hôtes dont d'autres services dépendent, videz ou migrez la charge avant, car le redémarrage coupe toutes les connexions.
2. Poser un filtre réseau en attendant le redémarrage. Il rejette les paquets TCP entrants porteurs d'options IP. Red Hat, AlmaLinux, CIQ et Ubuntu recommandent tous cette mesure. Voici la version nftables de l'avis d'AlmaLinux :

   sudo nft -f - <<'EOF'
   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
       }
   }
   EOF

   Pour la vérifier : sudo nft list table ip cve_2026_98432. Pour la retirer une fois le noyau corrigé démarré : sudo nft delete table ip cve_2026_98432.
3. Désactiver MPTCP là où il ne sert pas. sysctl -w net.mptcp.enabled=0, à rendre persistant dans /etc/sysctl.d/, et GODEBUG=multipathtcp=0 pour les services Go. Les écouteurs MPTCP déjà ouverts survivent au changement : redémarrez les services concernés. Cela ferme l'exploit démontré, pas la faille.
4. Utiliser le livepatch, si vous en avez un. KernelCare, SUSE Live Patching et leurs équivalents proposent parfois un correctif sans redémarrage pour votre noyau exact. C'est une solution d'attente jusqu'au vrai redémarrage.

Les limites du filtre nftables

Le filtre rend service, mais ses effets de bord figurent rarement dans les avis. Nous préférons les lister, parce qu'une règle « temporaire » a tendance à rester en place bien après l'incident.

• Il ne survit pas au redémarrage. Un hôte redémarré sans le nouveau noyau (coupure de courant, maintenance sans rapport) revient sans protection. Rendez la règle persistante, ou faites de la mise à jour du noyau et du redémarrage une seule opération.
• Il filtre aussi le trafic routé. Sur une passerelle VPN, un hyperviseur qui ponte des VM ou un nœud Kubernetes, les paquets porteurs d'options IP qui traversent la machine sont rejetés eux aussi. C'est en général souhaitable, mais notez-le dans le ticket de changement.
• Il bloque CIPSO. Les réseaux qui utilisent des étiquettes CIPSO (NetLabel, certains environnements de sécurité multiniveau) les transportent dans les options IPv4.
• Il ne couvre pas le trafic entre conteneurs d'un même hôte. Ces paquets ne passent jamais par le hook prerouting. Red Hat le confirme pour OpenShift : aucune atténuation n'existe encore pour le trafic entre pods.
• Il touche très peu de trafic légitime. Les options IP sont rares sur Internet, et souvent déjà supprimées par les routeurs. Le compteur de la règle permet de le vérifier avant de la retirer.

Que surveiller

Aucune signature de détection n'a été publiée. Sur les hôtes exposés et non corrigés, surveillez :

• les oops ou paniques du noyau qui coïncident avec des connexions entrantes ;
• des volumes inhabituels de paquets IPv4 porteurs d'options IP ;
• le compteur de la règle nftables, s'il augmente.

Aucun de ces signes ne prouve une attaque. Réunis sur un hôte non corrigé, ils justifient de l'isoler.

En cas de doute sur une exploitation réussie, considérez l'hôte entier comme compromis. Un attaquant root dans le noyau a accès à tout ce que la machine connaît, secrets et accès vers les autres systèmes compris.

Ce que cette faille change pour les équipes

On raisonnait jusqu'ici ainsi sur une course divulguée dans le noyau : critique sur le papier, difficile à exploiter en pratique, donc à traiter au prochain cycle de correctifs.

CVE-2026-98432 contredit ce raisonnement. Le bug a dix ans, il est subtil, et un modèle en a pourtant tiré un root à distance en moins d'une heure.

Nous ne pensons pas qu'il faille paniquer. Mais le délai entre divulgation et exploitation, qui permettait de corriger au rythme habituel, n'est plus acquis.

Face à ce type de faille, ce qui compte est très concret :

• savoir quels hôtes sont joignables depuis Internet ;
• savoir quel noyau tourne réellement sur chacun ;
• repérer les services Go qui ont ouvert un écouteur MPTCP à votre insu ;
• détecter l'hôte revenu d'une migration avec un noyau du trimestre dernier.

Un pentest annuel ne répond à aucune de ces questions. Il faut cartographier son système d'information et inventorier sa surface d'attaque externe, et le faire en continu.

Si les attaquants utilisent l'IA pour exploiter plus vite, les défenseurs ont intérêt à s'en servir aussi pour tester leur propre périmètre. Nous détaillons le fonctionnement d'un agent de pentest IA dans un article dédié. L'évasion de VM PwnEscape, deux semaines plus tôt, posait déjà la même question.

Ce que Flawfence peut voir, et ce qu'il ne voit pas

Flawfence ne lance pas d'exploit noyau contre vos serveurs, et ne prétend pas confirmer CVE-2026-98432 à distance. La version du noyau n'est pas visible de l'extérieur, et envoyer le vrai déclencheur risquerait de faire tomber l'hôte. Méfiez-vous des offres qui promettent le contraire.

Notre travail porte sur l'autre partie du problème, l'exposition. Flawfence :

• cartographie votre périmètre exposé sur Internet ;
• liste les services qui répondent en votre nom ;
• situe leurs versions observables dans les plages vulnérables connues, quand c'est possible ;
• vous alerte quand un nouvel hôte, une console oubliée ou un service réapparu après une migration se montre, sans attendre le prochain audit.

Questions fréquentes sur CVE-2026-98432

Qu'est-ce que CVE-2026-98432 ?

Un use-after-free dans le traitement des connexions TCP IPv4 du noyau Linux, noté 9,8 en CVSS. Un attaquant distant et non authentifié peut l'atteindre par n'importe quel port TCP exposé.

Un modèle Claude non publié en a tiré une preuve de concept qui obtient un shell root en 53 minutes environ, contre un serveur doté d'un écouteur Multipath TCP.

Est-elle exploitable à distance depuis Internet ?

Oui. Contrairement à beaucoup de bugs du noyau, celui-ci se déclenche avec des paquets TCP IPv4 ordinaires envoyés vers un port en écoute, sans authentification ni interaction. D'où le vecteur AV:N et la note de 9,8.

Faut-il Multipath TCP pour être vulnérable ?

Non. Le seul exploit root publié vise un écouteur MPTCP, mais le bug se trouve dans le TCP IPv4 ordinaire. Red Hat indique que RHEL, qui désactive MPTCP par défaut, reste vulnérable.

Désactiver MPTCP ferme un chemin d'exploitation démontré, pas la vulnérabilité.

Ubuntu est-il corrigé ?

Pas au 5 novembre 2026. La priorité est passée à « Critical » le 4 novembre, mais tous les noyaux (22.04, 24.04, 26.04, 26.10, variantes cloud comprises) restent marqués « en cours ».

En attendant, appliquez le filtre nftables qui rejette les paquets TCP IPv4 porteurs d'options IP, et désactivez MPTCP là où vous ne l'utilisez pas.

Quelle version du noyau corrige 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 distributions rétroportent le correctif sous leur propre numérotation, par exemple kernel-5.14.0-687.64.1.el9_8 pour RHEL et AlmaLinux 9, 6.1.190-1 pour Debian 12 et 7.0.14-25-pve pour Proxmox VE 9. Le tableau plus haut donne les autres.

Pourquoi Go est-il concerné ?

Depuis Go 1.24, la bibliothèque standard active Multipath TCP par défaut sur les sockets en écoute. Beaucoup de services Go exposent donc la configuration visée par l'exploit publié, sans que personne l'ait choisie.

GODEBUG=multipathtcp=0, ou une ligne godebug multipathtcp=0 dans go.mod, la désactive. L'équipe Go qualifie elle-même cette mesure d'atténuation fragile.

La faille est-elle exploitée dans la nature ?

Pas à notre connaissance au 5 novembre 2026. Aucun code public n'atteint l'exécution de code, aucune exploitation n'a été signalée, et la faille ne figure pas au catalogue KEV de la CISA. L'exploit d'Anthropic a été démontré en laboratoire et son code n'a pas été publié.

init_on_free=1 me protège-t-il ?

Non. L'option remet la mémoire à zéro quand elle est libérée, alors que la fuite lit de la mémoire encore utilisée. Un ingénieur noyau de CIQ l'a montré sur la liste oss-security. Les vraies protections sont le filtre réseau et le noyau corrigé.

Sources

• NVD, CVE-2026-98432
• Commit noyau e3f33b0a1d89 « ipv4: free inet_opt and ireq_opt after an RCU grace period »
• Anthropic, « Discovering vulnerabilities with Claude »
• Red Hat, RHSB-2026-016 et fiche CVE
• AlmaLinux, avis CVE-2026-98432
• Ubuntu Security, CVE-2026-98432
• Debian Security Tracker, CVE-2026-98432
• SUSE, CVE-2026-98432
• AWS, bulletin de sécurité 2026-160
• Forum Proxmox, « CVE-2026-98432 in Proxmox VE »
• Équipe sécurité de Go, « Protecting against CVE-2026-98432 when using Go programs » (oss-security)
• oss-security, Sultan Alsawaf (CIQ) sur init_on_free=1
• BleepingComputer, « Critical Linux kernel flaw allows remote root attacks on MPTCP servers »
• Verizon, Data Breach Investigations Report 2026