Faille Linux : après Cardano, Anza alerte les validateurs Solana sous Ubuntu, et Red Hat publie ses correctifs

Mise à jour du 2 novembre 2026, 5 h 55 UTC : Anza, qui développe le client de validation Agave pour Solana, a demandé aux validateurs sous Ubuntu de filtrer le trafic entrant et de désactiver deux fonctions réseau en attendant un noyau corrigé, ont rapporté The Defiant et TokenPost dans la soirée du 1er novembre, heure américaine. Red Hat a publié le 1er novembre des noyaux corrigés pour RHEL 8, 9 et 10, selon ses avis de sécurité. Le suivi d’Ubuntu, mis à jour pour la dernière fois le 30 octobre, n’indiquait toujours aucun correctif lors de notre lecture du 2 novembre. Aucun texte consulté ne donne d’échéance ni la part de la mise en jeu de Solana concernée.

Intersect, l’organisation des membres du réseau Cardano, a demandé le 30 octobre aux opérateurs de pools de mise en jeu de vérifier le noyau Linux de leur producteur de blocs et de leurs relais, puis d’installer un noyau corrigé et de redémarrer dès que leur distribution en publie un. La faille, CVE-2026-98432, reçoit un score CVSS de 9,8 sur 10. Elle se trouve dans le noyau Linux et non dans Cardano, et la mise à jour hebdomadaire d’Intersect ne dit rien des fonds, du consensus ni d’une exploitation.

Les opérateurs sous Ubuntu ne peuvent toujours pas suivre ce conseil. Lors de notre lecture du 2 novembre, son suivi de sécurité, mis à jour pour la dernière fois le 30 octobre, classait encore comme vulnérables les sept versions qu’blockchain that runs exactly as written when it is called, holding and moving funds according to its code, without an intermediary able to change the outcome.">smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool diverge, compared with simply holding the same tokens in a wallet. It becomes permanent when the provider withdraws.">il liste de la 16.04 à la 26.10. Red Hat, qui n’indiquait aucun noyau corrigé le 31 octobre, a depuis publié des correctifs pour RHEL 8, 9 et 10. Aucune exploitation dans la nature n’est signalée dans les sources consultées, et la faille ne figurait pas au catalogue des vulnérabilités exploitées connues de la CISA (toujours en version 2026.10.30) lors de notre vérification du 2 novembre. Cela décrit l’état de ces sources et ne prouve pas qu’aucune attaque n’existe.

Anza demande aux validateurs Solana sous Ubuntu d’agir sur la même faille

Solana est le deuxième réseau dont nous savons que les opérateurs ont été alertés. The Defiant a rapporté à 0 h 23 UTC le 2 novembre qu’Anza demandait aux opérateurs sous Ubuntu de filtrer le trafic entrant et de désactiver deux fonctions réseau en attendant un noyau corrigé. TokenPost a relayé la même alerte à 19 h 26, heure de l’Est américain, le 1er novembre, soit 0 h 26 UTC le 2 novembre. Nous n’avons trouvé aucune copie publique de l’avis d’Anza : ces éléments reposent donc sur ces articles.

Les mesures elles-mêmes ont été relayées par Tim Garcia, qui dirige les relations avec les validateurs à la Fondation Solana. Selon TokenPost, il a indiqué que la faille du noyau est corrigée mais qu’Ubuntu n’a publié aucun correctif, et qu’en attendant les validateurs doivent bloquer les paquets TCP entrants contenant des options IPv4, désactiver Multipath TCP et désactiver la migration des sockets de demande TCP. Le conseil est temporaire et vise les validateurs sous Ubuntu, pas tous les validateurs de Solana. La troisième mesure trouve un fondement dans le texte de la CVE, qui décrit un problème similaire de migration des sockets de demande lorsque le réglage net.ipv4.tcp_migrate_req vaut 1.

Ubuntu compte ici en raison de ce que documente Anza : sa page des prérequis indique « We build and run on Ubuntu 24.04 » (nous compilons et exécutons sur Ubuntu 24.04) et exige une adresse IPv4 publique. L’article de The Defiant, repris par cryptonews.net, date l’alerte du 1er novembre et explique que la prise de contrôle d’un hôte pourrait exposer la clé d’identité du validateur qui s’y trouve, et qu’un plantage du noyau pourrait interrompre la production de blocs. La page sur la sécurité d’Anza limite d’avance un autre risque : la paire de clés de retrait « ne devrait jamais être stockée sur votre validateur, à aucun moment ».

Plusieurs points restent inconnus. Aucune source consultée ne donne d’échéance, la part de la mise en jeu de Solana tournant sous Ubuntu, ni la proportion qui a appliqué ces mesures. Aucune ne dit qu’un validateur a été touché, ni si le logiciel de validation ouvre un écouteur MPTCP, condition de la démonstration publiée. Nous n’avons pas non plus pu établir si les opérateurs d’autres clients Solana ont reçu des consignes distinctes.

La contradiction est venue le même soir. TokenPost rapporte que 23pds, responsable de la sécurité de l’information de SlowMist, conteste l’idée que tout système Ubuntu offre un accès root sans clic. Selon cet article, l’exploitation suppose un serveur à l’écoute de MPTCP, fonction que Linux n’active pas par défaut, et il n’a vu aucune confirmation officielle d’une exploitation à grande échelle. Cela cadre mal avec l’avertissement de Damien Neil, de Go, cité plus bas, selon lequel la cause racine n’est pas spécifique à MPTCP.

Ce qu’Intersect a demandé aux opérateurs de pools Cardano

L’avis tient en quelques lignes, sous le titre « Security advisory for SPOs », dans la section consacrée aux mises à niveau de Cardano de la mise à jour hebdomadaire n° 135. Nous n’avons trouvé aucune publication à part. Il indique que des noyaux corrigés existent pour certaines distributions, tandis que d’autres, Ubuntu comprise, préparent encore les leurs, et renvoie vers la page d’Ubuntu consacrée à la faille.

« Si vous exploitez un pool de mise en jeu, vérifiez quel noyau utilisent votre producteur de blocs et vos relais », a écrit Intersect. Les opérateurs doivent ensuite appliquer le noyau corrigé et redémarrer. Davantage de consignes sont promises sur X et dans les canaux des SPO. L’avis ne donne aucun détail technique et ne prescrit aucun contournement.

Il ne faut pas confondre cet avis avec la préversion de Node 11.2 de la même mise à jour. Cette version embarque les fonctions du hard fork Dijkstra, Leios en moins, le chantier de passage à l’échelle dont nous avons raconté la fusion du code cette semaine. Mettre à jour cardano-node change le logiciel du nœud, pas le noyau du système d’exploitation, et ne règle donc rien pour cette faille.

CVE-2026-98432 : une situation de concurrence dans le code TCP de Linux

Selon la description d’Ubuntu, le bogue se situe dans la gestion de TCP sur IPv4 du noyau. Quand une connexion est en cours d’établissement, la mémoire qui contient ses options IP peut être libérée alors qu’un autre cœur du processeur la lit encore pour construire la réponse à une demande de connexion retransmise. Lire une mémoire déjà libérée s’appelle un « use-after-free ». Le correctif retarde la libération de cette mémoire jusqu’à ce qu’aucun lecteur ne puisse encore l’utiliser.

Le bulletin RHSB-2026-016 de Red Hat, daté du 30 octobre, indique qu’un attaquant distant et non authentifié pourrait exploiter cette situation de concurrence, avec à la clé une exécution de code à distance possible. Il ajoute : « L’exploitation exige un minutage précis des requêtes réseau, mais ne nécessite ni privilège ni interaction de l’utilisateur. » Tout système doté d’un noyau vulnérable et du réseau TCP sur IPv4 activé est concerné, précise Red Hat, et les machines qui acceptent des connexions TCP entrantes le sont plus directement. L’enregistrement CVE donne 4.4 comme première version du noyau touchée, et liste les correctifs amont dans les versions stables 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56 et 7.2.10.

Deux dates : la CVE le 15 octobre, l’exploit décrit le 27 octobre

Ubuntu et la base nationale américaine des vulnérabilités (NVD) donnent tous deux le 15 octobre comme date de publication de la CVE. La page d’Ubuntu a été mise à jour pour la dernière fois le 30 octobre, l’enregistrement de la NVD le 31 octobre. L’article de recherche d’Anthropic, qui décrit un exploit pour cette faille, est daté du 27 octobre. Cette date est celle de l’article : la page n’en donne aucune pour la CVE elle-même. L’avis d’Intersect est arrivé trois jours plus tard.

Les correctifs ont atteint les branches stables du noyau amont, pourtant les clients de Red Hat ont attendu jusqu’au 1er novembre, soit 17 jours après l’apparition de la CVE, et ceux d’Ubuntu attendaient toujours le 2 novembre. Les avis de Red Hat précisent qu’un redémarrage est nécessaire. Son bulletin, toujours daté du 30 octobre lors de notre relecture, continue de dire que les correctifs sont accélérés : les données CVE et les avis sont plus récents. Voici l’état par distribution, tel que lu le 2 novembre :

Un mainteneur de MPTCP conteste le score de 9,8

Selon l’article d’Anthropic, son modèle d’IA Claude a, après une première consigne, écrit un exploit qui permet à un attaquant distant d’exécuter des commandes en tant que root, sans identifiants, sur des serveurs Linux dotés d’un écouteur TCP multivoie (MPTCP). Sa démonstration a mis 48 minutes à faire fuiter un pointeur du noyau, puis cinq de plus à lancer une commande. Une course perdue fait seulement échouer la poignée de main, précise l’article, si bien que l’attaquant peut réessayer.

Matthieu Baerts a nuancé ce tableau le 30 octobre dans un fil du suivi de tickets de Go. Le fichier MAINTAINERS du noyau Linux le liste comme mainteneur du code MPTCP, même s’il n’a indiqué aucun rôle dans son commentaire. Il écrit que le reproducteur a tourné en laboratoire, a envoyé un nombre énorme de demandes de connexion et a utilisé MPTCP parce que, par chance, cela prenait moins de temps qu’avec TCP. Il ajoute qu’il est « à peu près sûr » que les options IPv4 sont déjà bloquées sur de nombreux réseaux, et que l’attaque semble très improbable hors laboratoire. « Je n’ai aucune idée de la façon dont ils ont obtenu un score de 9,8 à certains endroits », écrit-il, en qualifiant l’article de « pub ».

La veille, Damien Neil, qui répondait au nom du projet Go dans le même fil, s’était montré plus prudent. Il a écrit le 29 octobre que la cause racine « n’est pas spécifique à MPTCP ». À sa connaissance, personne ne savait si l’exécution de code était possible sans écouteur MPTCP, et il déconseillait de compter sur le contraire. L’avis de l’équipe de sécurité de Go, publié le même jour, présente un noyau corrigé comme la meilleure solution.

Les notations officielles ne tranchent pas. Red Hat juge la faille critique et classe ainsi son avis pour RHEL 8, même si l’avis pour RHEL 9, qui regroupe 18 CVE, et celui pour RHEL 10 portent la note globale « Important ». Le 31 octobre, sa page CVE qualifiait les chiffres CVSS de préliminaires ; cette mention avait disparu le 2 novembre. La page dit toujours qu’une exécution de code fiable exige un contrôle précis du tas, et que la faille provoque surtout un plantage ou une possible corruption de mémoire. Ubuntu affiche 9,8 avec une priorité « High ». L’enregistrement de la NVD portait toujours le statut « Received » le 2 novembre, ce qui signifie que la NVD ne l’a pas encore analysé.

Ce que l’on ignore pour les nœuds Cardano

Aucune des sources consultées ne dit si un hôte cardano-node peut être attaqué par cette faille, ni si ce logiciel ouvre un écouteur MPTCP, condition de la démonstration publiée. En général, les relais acceptent des connexions TCP entrantes venues du réseau, et Red Hat désigne ces machines comme les plus directement exposées. C’est notre propre lecture du fonctionnement des relais, pas une conclusion sur Cardano tirée d’une source.

L’avis d’Intersect ne mentionne ni les fonds ni le consensus, et aucune source consultée ne relie la faille à l’un ou l’autre. Il s’agit d’un défaut des systèmes d’exploitation des serveurs, pas du protocole Cardano. Déléguer ne remet pas d’ADA à un pool : « Vos ada restent dans votre portefeuille et restent dépensables à tout moment », indique cardano.org.

Nous n’avions trouvé aucune déclaration distincte de la Fondation Cardano ou d’Input Output au 31 octobre. L’avis d’Anza est le seul d’une autre chaîne que nous ayons trouvé, bien que la description de Red Hat couvre tout système Linux doté d’un noyau vulnérable et de TCP sur IPv4 activé.

Ce que les opérateurs Cardano et Solana peuvent faire maintenant

Les étapes ci-dessous viennent d’Intersect et des éditeurs. Ni l’avis d’Intersect ni les articles sur celui d’Anza ne donnent de consigne aux personnes qui délèguent leur staking. Nous n’avons pas pu lire l’avis d’Anza lui-même, et nous ne donnons donc aucune ligne de commande pour ses mesures : les validateurs sous Ubuntu doivent les prendre dans cet avis.

1. Vérifier quel noyau font tourner le producteur de blocs et chaque relais, comme le demande Intersect.
2. Le comparer à la page de sécurité de votre distribution, car la version corrigée varie selon la version.
3. Installer le noyau corrigé dès sa publication, puis redémarrer. Intersect cite explicitement le redémarrage, et les avis de Red Hat précisent que le système doit redémarrer pour que la mise à jour prenne effet.
4. Les utilisateurs d’AlmaLinux peuvent aider à tester les noyaux du dépôt de test, que le projet demande de vérifier avant tout usage en production.
5. Le bulletin de Red Hat donne une règle nftables provisoire qui rejette les paquets TCP IPv4 entrants portant des options IP. Il précise que la règle réduit l’exposition sans pouvoir empêcher complètement l’exploitation, et qu’elle peut perturber certaines charges de travail : à tester d’abord.
6. Pour les utilisateurs d’AlmaLinux seulement, et non une consigne d’Anza : l’article d’AlmaLinux du 30 octobre indique que, si MPTCP est actif et inutile, il faut lancer sudo sysctl -w net.mptcp.enabled=0. Cela n’arrête que les nouveaux sockets MPTCP, précise-t-il : listez les écouteurs encore ouverts avec sudo ss -lnMp et redémarrez les services concernés.

Red Hat est claire sur les limites de son filtre : « Appliquer les mises à jour de sécurité du noyau dès qu’elles sont disponibles est la seule solution complète. »

À surveiller ensuite : les noyaux corrigés d’Ubuntu, les produits Red Hat restants, l’analyse du score par la NVD, tout changement du catalogue de la CISA, les nouvelles consignes promises par Intersect, et tout texte public d’Anza.