Intersect, une organisation basée sur Cardano, a exhorté les opérateurs de pools de staking à appliquer les correctifs et à redémarrer leurs producteurs de blocs et leurs serveurs relais dès que des correctifs seront disponibles pour une vulnérabilité critique du noyau Linux.
Dans sa mise à jour du 30 octobre, Intersect a demandé aux opérateurs de vérifier les noyaux sur les deux types de serveurs et d'installer le noyau corrigé de leur distribution dès sa publication. La vulnérabilité, CVE-2026-98432, présente un score CVSS 3.1 de 9,8, soit critique, selon kernel.org.
La faille affecte la gestion par le noyau des connexions TCP IPv4 entrantes. Elle peut provoquer l'accès du noyau à une mémoire après qu'elle ait été libérée. Le bulletin de sécurité de Red Hat indique qu'un attaquant distant sans identifiants pourrait exploiter la condition de course pour exécuter du code ; sa description de vulnérabilité identifie également les plantages système et la corruption de mémoire comme des risques.
Pour Cardano, l'avertissement concerne à la fois les machines qui produisent les blocs et les relais les reliant au réseau plus vaste. La documentation opérateur de Cardano recommande de ne connecter les producteurs de blocs qu'à leurs propres relais ou à des relais de confiance afin de les protéger d'Internet. L'avis d'Intersect ne signale aucune exploitation contre Cardano ni ne quantifie le nombre de pools exécutant des noyaux vulnérables.
Correctifs et mesures intérimaires
Le suiveur d'Ubuntu, mis à jour le 30 octobre, liste ses noyaux standards pour Ubuntu 22.04, 24.04, 26.04 et 26.10 comme vulnérables, avec des correctifs en cours. Le bulletin du 30 octobre de Red Hat liste RHEL 8, 9 et 10 comme concernés et indique qu'il accélère la mise en œuvre des correctifs.
AlmaLinux a déclaré le 30 octobre que des noyaux corrigés pour ses versions 8, 9 et 10 étaient disponibles dans les dépôts de test, avant la sortie en production. Elle a indiqué qu'aucun noyau RHEL corrigé n'était disponible à ce moment-là. Ce bogue remonte à Linux 4.4, tandis que des correctifs amont ont été rétroportés sur les branches stables maintenues.
L'attaque démontrée a utilisé Multipath TCP, ou MPTCP. Les chercheurs d'Anthropic ont déclaré que leur preuve de concept pouvait envoyer des paquets à un serveur Linux avec un écouteur MPTCP et exécuter des commandes en tant que root, sans identifiants ni interaction utilisateur. Mais le Go Security Team a averti que le bogue sous-jacent n'est pas spécifique à MPTCP, donc les systèmes sans ces écouteurs peuvent également être vulnérables.
AlmaLinux recommande de désactiver MPTCP là où il n'est pas nécessaire et de redémarrer les services avec des écouteurs MPTCP existants : modifier le paramètre seul arrête uniquement la création de nouvelles sockets MPTCP.
Red Hat propose également une mitigation pare-feu qui filtre les paquets TCP IPv4 entrants contenant des options IP. Il avertit les opérateurs de tester la règle sur leurs charges de travail avant le déploiement et indique que le filtrage peut réduire l'exposition, mais ne peut pas empêcher complètement l'exploitation. Les deux fournisseurs soulignent que les mesures temporaires ne remplacent pas l'installation d'un noyau corrigé ; Intersect indique explicitement aux opérateurs de redémarrer après mise à jour.