Les développeurs de clients Ethereum ont déployé des mises à jour de sécurité d'urgence pour Teku et Besu après qu'une défaillance cryptographique chez l'autorité de certification indienne eMudhra a exposé certaines configurations de nœuds à des attaques potentielles. La faille aurait pu permettre à des attaquants de forger des certificats de confiance et d'intercepter les communications entre les composants de l'infrastructure Ethereum, bien que les développeurs aient confirmé que les configurations par défaut du mainnet Ethereum n'étaient pas concernées.

Les deux clients, qui soutiennent les opérations de la blockchain et l'infrastructure de validation, ont reçu des correctifs en urgence. Teku sert de client de la couche de consensus et Besu de client de la couche d'exécution, et les deux sont écrits en Java — un détail qui détermine la manière dont le correctif atteint les différentes configurations des opérateurs. Les chercheurs ont identifié des scénarios d'attaque potentiellement graves, mais les développeurs n'ont signalé aucune exploitation confirmée concernant les installations Teku touchées.

Comment la défaillance de certificats d'eMudhra a créé des risques de sécurité

L'incident remonte à une erreur cryptographique dans le processus de génération de certificats d'eMudhra en avril 2025. L'entreprise a généré huit clés d'autorité de certification intermédiaires avec une force cryptographique insuffisante, laissant leurs clés privées récupérables.

Les autorités de certification constituent le fondement du modèle de confiance HTTPS : les applications s'appuient sur leurs signatures pour confirmer que les serveurs auxquels elles se connectent sont authentiques. Un chercheur indépendant a découvert la faiblesse le 17 octobre 2026. Elle permettait à des attaquants de fabriquer des certificats frauduleux que des applications vulnérables pourraient prendre pour des certificats légitimes. Le problème est passé inaperçu pendant environ 18 mois malgré des audits de sécurité indépendants.

eMudhra a ensuite révoqué les certificats concernés et reconnu qu'une erreur de script avait produit les clés cryptographiques faibles. Reuters a rapporté que cet épisode a également conduit l'entreprise à se retirer de son activité mondiale de certificats de sécurité pour sites web, bien qu'eMudhra ait affirmé que son infrastructure et ses données clients n'avaient pas été compromises.

Teku et Besu publient des mises à jour de sécurité d'urgence

En réponse, les développeurs de clients Ethereum ont retiré la confiance accordée aux autorités de certification concernées de leurs distributions Docker. Teku a publié la version 26.10.3 le 27 octobre, tandis que Besu a publié la version 26.10.2 le 26 octobre.

Les correctifs ciblent les risques liés aux connexions HTTPS qui dépendent de chaînes de certificats compromises. Dans certaines configurations, des attaquants menant des attaques de type « man-in-the-middle » — relayant et modifiant discrètement le trafic entre deux parties — pourraient potentiellement manipuler les communications entre les validateurs et les services de signature externes. De telles attaques pourraient théoriquement rediriger les récompenses de frais de bloc vers des adresses contrôlées par les attaquants.

L'exploitation de ce scénario nécessiterait toutefois des conditions spécifiques, notamment des configurations vulnérables et la capacité d'intercepter le trafic réseau concerné. Les nœuds du mainnet Ethereum par défaut, sans connexions HTTPS touchées, ne figuraient pas parmi les expositions identifiées.

Vérifications Java supplémentaires pour les opérateurs Ethereum

Les opérateurs utilisant des images Docker mises à jour reçoivent les changements de confiance des certificats via leurs conteneurs, les images embarquant leur propre environnement d'exécution. Les administrateurs qui exécutent Teku ou Besu directement sur des serveurs doivent cependant inspecter séparément leurs installations Java et leurs magasins de certificats de confiance. La mise à jour du client Ethereum seule peut ne pas suffire à éliminer la vulnérabilité si l'environnement Java sous-jacent continue d'accorder sa confiance aux certificats concernés.

Cet épisode souligne comment des faiblesses dans l'infrastructure de sécurité externe peuvent créer des risques pour les applications blockchain sans compromettre le protocole blockchain lui-même. Pour les validateurs Ethereum, maintenir la sécurité du logiciel client et des configurations de certificats reste essentiel pour protéger l'infrastructure opérationnelle et les récompenses potentielles.