Les développeurs d'Ethereum ont résolu deux vulnérabilités distinctes qui auraient pu mettre en danger les dépôts et les récompenses des validateurs : l'une impliquait de faibles certificats de sites web, l'autre était intégrée dans les règles provisoires de la prochaine mise à niveau Glamsterdam du réseau. Teku, un client de consensus, et Besu, un client d'exécution, ont chacun publié des correctifs pour remédier à cette exposition. Les nœuds Ethereum font fonctionner un client de consensus et un client d'exécution côte à côte, ce qui signifie que les deux couches de la pile du nœud nécessitaient le même nettoyage des certificats.

Teku a publié la version 26.10.3 le 27 octobre, un jour après que Besu a livré la version 26.10.2 le 26 octobre. Les deux versions retirent les autorités de certification concernées des images Docker utilisées pour faire fonctionner les nœuds Ethereum, selon la page de versions de Teku.

Faiblesse des clés de certificats signalée

Les chercheurs ont découvert le 17 octobre que huit certificats intermédiaires émis par l'Indien eMudhra reposaient sur des clés privées que des attaquants pouvaient calculer à partir d'informations publiquement disponibles. Avec ces clés, les attaquants auraient pu émettre des certificats pour des services contrefaits. eMudhra a révoqué les certificats, mais certaines installations Java continuaient de leur faire confiance, car Java ne vérifie pas la révocation des certificats par défaut. Teku et Besu sont tous deux écrits en Java, ce qui explique comment cette faiblesse a touché l'exploitation des nœuds Ethereum.

Cette découverte est survenue la même semaine où Google a présenté un système de sécurité pour la conservation de cryptomonnaies conçu pour répartir les clés privées entre plusieurs environnements distincts.

Comment les frais des validateurs auraient pu être détournés

La faille des certificats était importante car les validateurs dépendent de connexions à des services externes. Un attaquant capable d'intercepter une telle connexion pouvait se faire passer pour le service situé à l'autre extrémité. Teku a averti qu'une connexion falsifiée vers un nœud distant pouvait entraîner le versement des frais de bloc à une adresse contrôlée par un attaquant. Les services de signature externes présentaient un risque supplémentaire dans les configurations concernées, car des attaquants pourraient obtenir des signatures redirigeant les récompenses.

« Un nœud Teku par défaut sur le mainnet n'est pas concerné et ne nécessite aucune action », a déclaré Teku. L'équipe du client n'a signalé aucune exploitation connue.

Règles de dépôt de Glamsterdam corrigées

Parallèlement, les développeurs ont révisé les règles provisoires de Glamsterdam après que le chercheur avsetsin a identifié une erreur de routage des dépôts. Ils ont également reporté la mise à niveau du testnet Hoodi, initialement prévue pour le 26 octobre.

Selon la version antérieure du projet, un builder et un validateur partageant une même clé publique auraient pu provoquer l'entrée de dépôts de staking dans le compte du builder. Glamsterdam est conçu pour séparer la construction des blocs de la validation, et la proposition révisée trie les dépôts en attente selon les identifiants de retrait (withdrawal credentials), distinguant ainsi les dépôts des validateurs de ceux des builders.

Les équipes clientes ont d'abord rejeté la correction le 19 octobre faute d'accord. Les développeurs ont ensuite ajouté des tests et fusionné les règles révisées le 26 octobre.

Des prochaines étapes différentes pour les opérateurs de nœuds

La correction de Glamsterdam a été intégrée aux spécifications d'Ethereum, mais les équipes logicielles doivent encore l'implémenter. Glamsterdam a déjà fonctionné sur le testnet Sepolia, tandis que Hoodi attend une nouvelle date d'activation.

Les opérateurs faisant tourner Teku ou Besu en dehors de Docker doivent mettre à jour Java séparément. Le risque lié aux certificats couvrait les paiements issus des gas fees d'Ethereum, tels que les priority fees versés aux validateurs, et non les soldes ordinaires des portefeuilles des utilisateurs. Teku a conseillé aux utilisateurs de Java 26, non pris en charge, de passer à Java 25.

Les correctifs de certificats résolvent le problème des images Docker concernées, tandis que le correctif de Glamsterdam attend d'être adopté par l'ensemble de l'écosystème de clients d'Ethereum.