Faille TCP du noyau Linux CVE-2026-98432 : ce que le RGPD vous impose maintenant

Une faille du noyau Linux, référencée CVE-2026-98432, permet à un attaquant distant et sans identifiants de corrompre la mémoire d’un serveur au moment où il accepte une connexion TCP en IPv4. L’équipe CVE du noyau lui attribue 9,8 sur 10. Red Hat a publié ses correctifs le 1er novembre 2026 ; au 2 novembre, Ubuntu n’en propose toujours aucun.

Si votre logiciel métier, votre dossier informatisé ou votre portail adhérents tourne sur un serveur Linux, chez vous ou chez un hébergeur, vous êtes concerné. Le sujet relève de la DSI, et il engage aussi le responsable de traitement au titre de l’article 32 du RGPD.

Comment fonctionne la faille

Le défaut se situe dans la poignée de main TCP, la négociation qui ouvre chaque connexion. Quand la connexion s’établit, le noyau transmet au nouveau socket les options IP de la demande en attente, sans les copier. Si ce socket disparaît pendant qu’un autre processeur lit encore ces options pour répondre à une demande renvoyée, le noyau lit une zone mémoire déjà libérée. Les spécialistes parlent de « use-after-free ».

Le bug remonte à Linux 4.4, sorti fin 2015. IPv6 n’est pas touché, car le noyau y copie les options. Le correctif, appliqué par les développeurs du noyau le 5 octobre, fait attendre la libération de la mémoire jusqu’à ce qu’aucun processeur ne la lise plus.

L’attaquant n’a besoin d’aucun compte et l’application n’en voit rien : il suffit qu’un port TCP du serveur soit joignable.

Des scores de gravité qui ont varié de 5,9 à 9,8

L’équipe CVE du noyau a ajouté la note de 9,8 le 24 octobre, neuf jours après la publication de la CVE. Elle juge la complexité d’attaque faible : l’attaquant envoie une demande de connexion portant des options IPv4 (Record Route ou Timestamp), puis la renvoie jusqu’à gagner la course. Selon elle, il peut alors récupérer de la mémoire du noyau, la corrompre ou faire planter la machine.

Red Hat a d’abord affiché 5,9 sur sa page CVE, en estimant la course difficile à gagner, puis 8,1 dans son fichier d’avis. Oracle et SUSE retiennent aussi 8,1, Amazon 7,0. Le 30 octobre, Red Hat a relevé sa propre évaluation au niveau critique, à 9,8.

Un DSI qui aurait classé la faille d’après le premier score de Red Hat l’aurait renvoyée au cycle trimestriel. Quand les éditeurs divergent, prenez la note la plus haute comme référence de priorité, et documentez ce choix.

Un exploit écrit par un modèle d’IA

Le correctif du noyau crédite Xinyang Ge, chercheur chez Anthropic, pour le signalement. Le 27 octobre, Anthropic a indiqué que son modèle Claude avait écrit, après une première série d’instructions, un exploit donnant un accès root à distance sur des serveurs Linux dotés d’un listener Multipath TCP (MPTCP, une extension qui fait passer une connexion par plusieurs chemins réseau).

La course force d’abord le noyau à renvoyer des octets en trop, jusqu’à ce qu’une réponse contienne une adresse mémoire du noyau, ce qui neutralise la randomisation KASLR. Le même bug sert ensuite à déborder un tampon et à remplacer un pointeur de rappel par l’adresse d’une charge déjà placée en mémoire, qui exécute une commande en root. Une tentative ratée ne fait échouer que la connexion concernée, sans plantage, ce qui autorise les essais répétés. Dans le test d’Anthropic, la fuite d’adresse a pris 48 minutes, l’exécution de commande 5 minutes de plus.

Anthropic n’a publié ni le code, ni la version du noyau testée, ni la configuration. Au 2 novembre, aucune exploitation réelle n’est signalée et la faille ne figure pas au catalogue KEV de la CISA. L’équipe sécurité de Go rappelle que les programmes Go activent MPTCP par défaut sur leurs sockets d’écoute depuis Go 1.24, et que des systèmes sans MPTCP peuvent rester vulnérables à des attaques voisines.

Une machine a produit un exploit fonctionnel sur un bug vieux de dix ans. Le temps qui sépare un correctif publié d’une attaque industrialisée raccourcit d’autant.

Où en sont les correctifs au 2 novembre 2026

Debian, Oracle Linux, SUSE, Amazon Linux et désormais Red Hat proposent des noyaux corrigés ; Ubuntu reste le grand absent.

Pour un noyau compilé soi-même, le correctif figure dans les versions 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 branches 4.4 à 5.4, en fin de vie, ne recevront rien.

Ce que la DSI doit faire maintenant

Là où un noyau corrigé existe, il faut l’installer puis redémarrer : un noyau mis à jour ne s’applique qu’au redémarrage, sauf correctif à chaud proposé par l’éditeur. Les serveurs exposés à Internet passent en premier.

Pour savoir si une machine est corrigée, lisez le journal des modifications du paquet plutôt que le numéro de version. Sur Debian et Ubuntu : apt changelog linux-image-$(uname -r) | grep CVE-2026-98432. Sur RHEL et dérivés : rpm -q --changelog kernel-$(uname -r) | grep CVE-2026-98432.

Sur Ubuntu, il n’y a rien à installer pour l’instant. Red Hat a publié dans son bulletin RHSB-2026-016 une règle de filtrage nftables qui écarte les paquets déclencheurs ; elle réduit l’exposition sans remplacer le correctif. Pour les programmes Go, la variable GODEBUG=multipathtcp=0 désactive MPTCP par défaut, mais l’équipe Go qualifie elle-même cette parade de fragile, puisqu’un seul listener MPTCP oublié suffit.

Chez la plupart de nos clients, le serveur appartient à un éditeur ou à un hébergeur. Celui-ci doit vous dire, par écrit, quelle distribution il utilise et à quelle date il aura redémarré sur un noyau corrigé.

L’angle RGPD : article 32, sous-traitants et violations

L’article 32 impose des mesures de sécurité adaptées au risque, compte tenu de l’état des connaissances. Une faille notée 9,8, publique, avec un correctif disponible et un exploit décrit fait partie de cet état des connaissances. Laisser un serveur qui héberge des données de santé sur un noyau vulnérable plusieurs semaines après la sortie du correctif deviendrait difficile à justifier devant la CNIL.

L’article 28 oblige le sous-traitant à prendre ces mêmes mesures et à mettre à votre disposition les informations qui le démontrent. Vous êtes donc fondé à interroger vos éditeurs et hébergeurs sur la distribution utilisée, la date d’application du correctif, la mesure d’attente retenue pour les serveurs Ubuntu et l’existence de journaux couvrant la période d’exposition. Pour des données de santé confiées à un hébergeur certifié HDS, la question porte aussi sur l’infrastructure qu’il exploite pour vous.

Une vulnérabilité non exploitée ne constitue pas une violation de données. Si un serveur exposé montre des signes de compromission (plantages inexpliqués du noyau, connexions anormales, processus inconnus), l’analyse change : l’article 33 fixe 72 heures pour notifier la CNIL à compter de la prise de connaissance, et toute violation, notifiée ou non, doit être consignée dans le registre prévu par l’article 33.5.

Le principe de responsabilité de l’article 5.2 demande enfin une trace écrite. Notez la date à laquelle vous avez pris connaissance de la faille, les serveurs concernés, les réponses des sous-traitants, la date des correctifs et, pour Ubuntu, la mesure d’attente choisie. En cas de contrôle, ce dossier vaudra davantage qu’une affirmation orale.

Garder la trace avec DPO SUITE

Sans inventaire à jour des serveurs et des sous-traitants, personne ne sait en une heure quels traitements reposent sur un noyau Ubuntu exposé. DPO SUITE rattache serveurs, logiciels et sous-traitants aux traitements du registre, permet d’envoyer un questionnaire d’audit à un sous-traitant et suit les incidents de sécurité avec le calcul du délai de 72 heures. Les DPO du réseau DPO FRANCE accompagnent nos clients dans la relecture des réponses des prestataires et la validation des décisions prises.