Les clés de l’autorité de certification eMudhra valaient entre 4 et 237 : Obol corrige Charon, bots crypto et serveurs à mettre à jour

Mise à jour du 22 octobre 2026, 5 h 30 UTC : Obol, dont le logiciel Charon fait tourner des validateurs distribués sur Ethereum, a publié Charon v1.11.2 le 21 octobre vers 15 h 10 UTC et la présente comme une version obligatoire pour tous les opérateurs. Le correctif passe Charon à Go 1.27.3, qui intègre la correction de la CVE-2026-111943, l’identifiant de l’affaire eMudhra, et retire la confiance aux racines emSign ECC Root CA – G3 et AAA Certificate Services dans son image Docker. La note de version rattache le correctif aux certificats d’eMudhra et ne fait état d’aucune compromission des clés d’Obol. Selon Crypto Briefing et The Defiant, les clusters d’Obol sur le réseau principal détiennent 422 862 ETH d’après le dernier relevé quotidien d’Obol, et Crypto Briefing écrit que rien dans l’annonce n’indique que des fonds aient été touchés. Détails dans la nouvelle partie ci-dessous.

Huit clés privées d’autorités de certification intermédiaires d’eMudhra, une entreprise indienne qui délivre des certificats web, étaient de minuscules nombres : le plus petit valait 4, le plus grand 237. Mozilla a confirmé la faiblesse dans un rapport d’incident ouvert le 18 octobre et rendu public le 20 octobre 2026, le jour où le chercheur Scott Helme a publié les valeurs. Avec ces clés, n’importe qui pouvait signer un certificat HTTPS d’apparence légitime pour n’importe quel domaine. Firefox, Chrome, Safari et Edge ont bloqué les chaînes de certificats d’eMudhra entre le 17 et le 20 octobre. Les logiciels qui tournent hors d’un navigateur, comme les scripts curl, Python et Node, les services Go et les applications Electron, continuent de leur faire confiance tant que leur liste de certificats n’est pas mise à jour.

Pour les utilisateurs de crypto, ce second groupe est celui qui compte. Les bots de trading connectés aux plateformes, les back-ends de portefeuilles, les outils de nœuds et les portefeuilles de bureau bâtis sur Electron émettent tous des requêtes HTTPS sans passer par un navigateur. Aucune attaque exploitant ces clés n’a été signalée et aucune perte en crypto n’est connue. Les phrases de récupération, les portefeuilles matériels et les clés secp256k1 qui contrôlent bitcoins et ethers ne sont pas concernés : c’est une affaire de mise à jour logicielle, pas un piratage crypto.

Certificats eMudhra compromis : ce qui a cédé et ce qui tient

Une autorité de certification (AC) atteste qu’un site est bien celui 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 prétend être, et les AC racines confient la signature quotidienne à des certificats intermédiaires. Les huit clés brisées appartiennent à de tels intermédiaires, pas à des sites. Chaque clé protège deux certificats d’AC, l’un sous la racine d’eMudhra, l’autre signé en croisé par Sectigo, soit 16 au total, d’après le ticket Mozilla et Helme. Six servent au TLS, deux à la signature de code. Sectigo a précisé dans le ticket que la racine utilisée pour les signatures croisées avait déjà quitté depuis un certain temps les magasins de confiance de Chrome et de Mozilla, mais qu’elle reste approuvée par Microsoft et Apple.

Le chiffrement lui-même n’a jamais été faible. Cloudflare, qui a dû corriger son propre logiciel client, l’exprime ainsi : « Ce travail concerne l’authentification par certificat, pas une faiblesse des algorithmes de chiffrement de TLS. » Le risque est l’usurpation d’identité. Un attaquant qui détient une clé pourrait fabriquer un certificat pour, disons, l’API d’une plateforme d’échange, mais il lui faudrait encore se placer entre la victime et le vrai serveur, sur un Wi-Fi hostile, un routeur compromis ou un réseau frauduleux, pour s’en servir. C’est donc un outil d’attaque de l’homme du milieu, pas un moyen bon marché de monter un site d’hameçonnage que les gens atteignent en cliquant sur un lien.

Des clés privées entre 4 et 237, retrouvées en moins d’une seconde

Les clés sont des clés à courbe elliptique sur la courbe NIST P-384. Sur cette courbe, une clé privée est un nombre et la clé publique est ce nombre multiplié par un point de départ fixe. Une clé P-384 correctement générée est tirée dans un espace d’environ 10¹¹⁵ valeurs. Dennis Jackson, de Mozilla, a écrit dans le ticket que les clés d’eMudhra étaient « en pratique des zéros partout, sauf le dernier octet », ce qui laisse au plus 255 candidats. L’attaquant n’a qu’à calculer 1 fois le point, 2 fois, 3 fois, et à comparer chaque résultat avec la clé publique inscrite dans le certificat.

Helme a fait exactement cela. « Je les ai toutes retrouvées à partir de leurs certificats publics sur mon ordinateur portable à l’instant, et cela a pris moins d’une seconde », écrit-il dans son compte rendu. Une mise à jour du même billet ajoute que « Claude a pu retrouver les clés privées avec une seule requête ». Jackson rapporte quelque chose de semblable dans le ticket : des agents d’IA exécutés en local ont retrouvé une clé du premier coup à partir d’une consigne d’une ligne. Voici les valeurs publiées par Helme :

eMudhra n’a publié aucune déclaration de son côté ; sa version des faits figure dans les commentaires du ticket Mozilla. L’entreprise met en cause un défaut du script de sa cérémonie de génération de clés, qui a créé une seconde paire de clés, plus faible, dans le module de sécurité matériel (HSM). Les étiquettes des clés étant proches, les clés faibles ont été utilisées par erreur pour les demandes de certificats. eMudhra dit analyser encore le code : l’analyse des causes n’est donc pas terminée. Selon elle, les clés RSA produites le même jour ont suivi un autre chemin et ne sont pas touchées, et ses séries ECDSA A et A-1 ont été générées sur des HSM Entrust pour un usage limité à l’Inde. Mozilla n’a confirmé ni l’un ni l’autre point : Jackson écrit qu’il n’a pas réussi à casser les clés A et A-1 malgré un effort bien plus important, et qu’il n’avait pas encore commencé sur les clés RSA.

D’une cérémonie de clés en avril 2025 à un blocage dans les navigateurs en moins de trois heures

Helme compte une fenêtre de 17 mois : « Cela fait une fenêtre de 17 mois, et il n’y a aucun moyen de savoir si quelqu’un en a profité. » Les principales dates, en UTC, d’après le ticket Mozilla, le blog de Mozilla, Cloudflare et Helme :

• Le 30 avril 2025, les intermédiaires concernés ont été générés lors d’une seule cérémonie de clés chez eMudhra ; Sectigo les a signés en croisé en mai 2025, selon Helme.
• Le samedi 17 octobre 2026, un chercheur a signalé la faille aux éditeurs de navigateurs, et Mozilla a reçu le rapport à 20 h 06.
• À 22 h 59 le même soir, Mozilla avait poussé la révocation de confiance dans Firefox via sa liste OneCRL, « moins de 3 heures après la réception du rapport », selon son blog sécurité ; Chrome a lui aussi bloqué les intermédiaires dans la soirée.
• Le 18 octobre, entre 09 h 24 et 09 h 38, eMudhra a révoqué les huit certificats, d’après le ticket.
• Le 19 octobre, Sectigo a fini de révoquer ses signatures croisées, Apple a bloqué les chaînes, Mozilla a commencé à alerter les autres exploitants de magasins de confiance et Cloudflare a été informé vers 17 h 00.
• Le 20 octobre, Microsoft a appliqué son blocage, Mozilla a publié Firefox 158.0.1, Firefox ESR 115.43.1 et 153.5.1 ainsi que NSS 3.131.1, et le ticket est devenu public.

Le 20 octobre, Mozilla a aussi décidé le retrait d’urgence de la racine qui coiffe ces intermédiaires, « emSign ECC Root CA – G3 », et Chrome a indiqué dans le ticket qu’il suivrait une voie semblable. NSS 3.131.1 retire cette racine de la liste de confiance. eMudhra estime qu’environ 30 000 certificats de clients doivent désormais migrer vers une autre chaîne, dont environ 97 % émis par le protocole automatisé ACME.

Les navigateurs vérifient la transparence des certificats ; curl, Python et Node ne le font pas

Les utilisateurs de navigateurs étaient protégés avant même les blocages. Chrome, Firefox et Safari exigent que les certificats figurent dans les journaux publics de transparence des certificats (Certificate Transparency, CT), et aucun certificat issu de ces intermédiaires n’y est apparu depuis avril 2025, note l’avis de Jackson.

La plupart des autres logiciels fonctionnent autrement. Ils lisent un lot de certificats stocké sur disque, vérifient rarement la révocation et ignorent les journaux CT. L’avis publié sur le site de Jackson le dit sans détour : « de nombreux clients extérieurs à l’écosystème des navigateurs n’imposent pas la transparence des certificats. »

Helme a testé cet écart avec un serveur local présentant un certificat pour api.stripe.com rattaché à l’un des intermédiaires brisés. Avec les réglages par défaut, curl a affiché « SSL certificate verify ok », Python a mené la négociation à terme et Node a renvoyé « authorized: true ». Cela s’est vérifié sur toutes les machines Linux et macOS essayées. Sous Windows, le système acceptait la chaîne tant que la vérification de révocation n’était pas activée.

La révocation n’aide pas ces clients. « Le fait qu’eMudhra et Sectigo aient révoqué ces intermédiaires ne leur sert donc strictement à rien », écrit Helme, car beaucoup de programmes ne demandent jamais si un certificat a été révoqué. Seul un nouveau lot de certificats, ou une bibliothèque qui embarque sa propre liste à jour, retire cette confiance. Cloudflare indique : « Notre revue de sécurité n’a pas identifié d’exploitation active de ce problème sur les services de Cloudflare. »

Pourquoi les bots crypto, les back-ends de portefeuilles et les applications Electron sont exposés

CoinDesk a fait le lien avec la crypto le 21 octobre : les bots de plateformes, les scripts de trading et les back-ends de portefeuilles tournent souvent sur Python, Node ou Go. En théorie, un faux certificat pour l’API d’une plateforme permettrait à un attaquant présent sur le même réseau de lire ou de modifier le trafic d’un bot. Helme souligne que les appels d’API de serveur à serveur transportent des secrets dans leurs en-têtes ; pour un bot de trading, il s’agit de ses clés d’API de la plateforme. C’est un scénario, pas un incident. Mudit Gupta, directeur technique de Polygon Labs, a déclaré à CoinDesk : « Ce n’est pas un problème propre à la crypto. » Il y voit un risque générique d’attaque de l’homme du milieu, qui vise surtout les gens dont les logiciels sont anciens ou non corrigés, et estime que les utilisateurs de crypto qui tiennent à jour leurs portefeuilles, leurs outils de trading et leurs appareils courent un risque moindre.

Les personnes concernées sont celles qui exécutent du code : exploitants de bots et de nœuds, équipes avec des portefeuilles ou des explorateurs auto-hébergés, utilisateurs de portefeuilles de bureau Electron, qui embarquent leur propre liste de confiance. Nous n’avons trouvé aucune déclaration d’une plateforme ou d’un fournisseur de portefeuilles disant avoir été touché, ni aucune disant être à l’abri. Un cas concret vient désormais du staking : le 21 octobre, Obol a livré une version obligatoire de Charon à ses opérateurs de validateurs distribués, détaillée dans la partie suivante.

Les clés de cette affaire n’ont rien à voir avec celles qui détiennent des fonds. La clé privée d’une adresse bitcoin ou ether vit sur la courbe secp256k1 et c’est votre portefeuille qui la génère ; votre phrase de récupération ne passe jamais par une autorité de certification. Rien ici n’impose de déplacer des fonds.

Charon v1.11.2 d’Obol : ce que doivent faire les opérateurs de validateurs distribués

Charon est l’intergiciel qui permet à plusieurs opérateurs de faire tourner ensemble un même validateur Ethereum, ce qu’on appelle la technologie des validateurs distribués (DVT). Le journal des modifications de la v1.11.2 tient en une ligne : passage à Go 1.27.3 et retrait de la confiance aux racines emSign et AAA dans l’image. La modification a été fusionnée sur la branche principale le 21 octobre à 14 h 00 UTC (pull request n° 4796), puis reportée sur la branche v1.11 à 14 h 54 UTC (n° 4799), ce qui fait passer Charon de Go 1.26.6 à 1.27.3 pour la correction de crypto/x509. Le second volet illustre le cas des conteneurs décrit plus haut : l’image d’exécution, basée sur Debian, marque les deux racines comme non fiables dans sa configuration de certificats, pour wget et les autres outils hors Go, en attendant que le paquet ca-certificates de Debian les retire.

Les montants en jeu sont élevés. Crypto Briefing et The Defiant font état de 422 862 ETH sur les clusters d’Obol du réseau principal, d’après le dernier relevé quotidien d’Obol, sans en donner la date. Avec un ether vers 2 444 $ à 4 h 37 UTC le 22 octobre, cela représente environ 1,03 milliard de dollars, selon notre calcul. C’est le montant mis en staking via les clusters d’Obol, pas un montant menacé. Crypto Briefing écrit que rien dans l’annonce n’indique que des fonds aient été touchés. Aucun slashing, aucune interruption ni aucune perte n’ont été signalés.

Obol n’a publié ni avis de sécurité ni billet de blog sur l’affaire ; la note de version est sa seule déclaration. Elle ne dit pas comment Charon utilise les racines concernées, ni ce qu’un attaquant muni d’un faux certificat pourrait faire contre un cluster. Dans les clusters d’Obol, les clés de validateur sont réparties entre opérateurs par une génération de clés distribuée et n’ont rien à voir avec les certificats TLS, mais c’est le principe général du système, pas une déclaration d’Obol sur ce cas.

Ce que les opérateurs peuvent faire, d’après la version et ses pull requests :

• Passer chaque nœud Charon du cluster en v1.11.2 ou plus récent ; Obol la déclare obligatoire pour tous les opérateurs et compatible avec Charon v1.0 et suivantes.
• Si vous utilisez l’image Docker, récupérer l’image v1.11.2 et recréer le conteneur, car le binaire Go et le magasin de certificats se trouvent tous deux dans l’image.
• Si vous compilez Charon vous-même, utiliser la chaîne d’outils Go 1.27.3 et vérifier le lot de certificats de votre propre image d’exécution.
• Conseil de notre part, pas d’Obol : mettre aussi à jour les conteneurs du nœud de consensus, du client validateur et de la supervision installés à côté de Charon, car chacun lit son propre lot de certificats.
• Prévoir la mise à jour suivante : la v1.11.2 n’est pas prête pour Gloas, le volet consensus de Glamsterdam. Sur Hoodi, tous les nœuds d’un cluster doivent tourner en v2.0.0-rc2 ou plus récent, qui contient le même correctif Go, avant le fork du 26 octobre 2026 à 17 h 42 min 48 s UTC ; sur le réseau principal, il faut attendre une v2.0.0 définitive, selon Obol.

Notre page sur la mise à jour Glamsterdam sur le testnet Hoodi suit cette échéance.

Mettre à jour les certificats de sécurité aujourd’hui, et un test curl en une ligne

L’avis de Jackson tient un tableau des versions corrigées. Voici les principales telles qu’affichées le 21 octobre, plus le client de tunnel de Cloudflare, tiré de l’article de Cloudflare, et Charon d’Obol, tiré de sa note de version :

Les étapes concrètes pour qui exploite des bots ou une infrastructure crypto :

• Mettez à jour le paquet ca-certificates du système sur chaque serveur, VPS et ordinateur portable qui exécute vos scripts.
• Passez certifi à la dernière version dans chaque environnement virtuel Python, car requests et de nombreux SDK de plateformes lisent certifi plutôt que le magasin du système.
• Reconstruisez les images de conteneurs, qui figent le lot de certificats au moment de la construction, puis redéployez-les.
• Mettez à jour les portefeuilles et outils de bureau fondés sur Electron dès que leurs éditeurs publient une version bâtie sur un Electron corrigé.
• Ne « réglez » jamais une erreur de certificat en désactivant la vérification ; Cloudflare met précisément en garde contre cela.

Puis testez. Jackson exploite des hôtes qui présentent des certificats issus des chaînes brisées. Depuis la machine et l’environnement que votre bot utilise réellement, lancez :

curl https://dv-g3b-emudhra.we-have-a-problem.com/

Une erreur de certificat est le résultat attendu : elle signifie que le client ne fait plus confiance aux intermédiaires compromis. Un second hôte, dv-g3b-aaa-emudhra.we-have-a-problem.com, vérifie la voie signée en croisé par Sectigo. Si curl charge la page, c’est que le lot de certificats qu’il lit est encore ancien. Utilisateurs de Mac, attention : Jackson indique que macOS bloque lui-même les intermédiaires, mais que le /usr/bin/curl intégré vérifie par rapport à /etc/ssl/cert.pem, qui n’a pas été mis à jour. Cloudflare ajoute une précaution : testez par le chemin TLS propre à l’application, car une application Node ou Electron peut ne pas utiliser le même lot que curl.

Rien à voir avec l’affaire des graines des courbes NIST

Il y a quatre jours, nous avons raconté que Claude avait fait remonter les graines publiées des courbes NIST à une horloge de 1997, une affaire qui touchait elle aussi la courbe P-384. Les deux sujets sont sans rapport. Cet article portait sur la manière dont les paramètres de la courbe avaient été choisis, et Bitcoin comme Ethereum utilisent secp256k1, qui n’a pas de graine de ce type. Dans le cas d’eMudhra, la courbe fonctionne comme prévu ; c’est l’entreprise qui a choisi des clés privées minuscules.

Les petits espaces de clés ont déjà vidé des portefeuilles crypto

La comparaison qui suit est celle de Coindaro, pas celle de Mozilla ni de Helme, et aucune source consultée ne la fait. eMudhra appartient à une famille de défaillances que la crypto a déjà rencontrées plusieurs fois : un secret qui semble valide mais provient d’un espace assez petit pour être parcouru.

Dans l’affaire Milk Sad, révélée le 8 août 2023, la commande « bx seed » de Libbitcoin Explorer tirait les graines de portefeuilles d’environ 32 bits d’entropie issus de l’horloge, et le principal vol, le 12 juillet 2023, a porté sur environ 29,65 BTC (l’équipe de Libbitcoin conteste qu’il s’agisse d’un bug). En septembre 2022, 1inch a montré que l’outil d’adresses personnalisées Profanity initialisait les clés Ethereum avec une valeur de 32 bits, soit environ 4 milliards de points de départ ; des experts cités par The Block ont rattaché la perte de 160 millions de dollars de Wintermute ce mois-là à une adresse Profanity, ce que le directeur général de Wintermute a attribué à une erreur humaine interne.

Le 19 octobre, veille de la publication du ticket eMudhra, nous rapportions que Qubic avait arrêté sa chaîne après que des graines de portefeuilles faibles ont permis à un attaquant de vider 1 404 portefeuilles. La différence tient au résultat. Dans ces affaires, des fonds ont été pris. Chez eMudhra, les secrets faibles protégeaient des certificats, et aucun vol n’est connu.

Ce que l’on ignore encore

Savoir si quelqu’un a utilisé les clés pendant ces 17 mois est impossible à trancher, puisque les clients qui ne vérifient pas la CT ne laissent aucune trace. Savoir si un vrai certificat de site a été émis depuis les intermédiaires brisés repose sur la parole d’eMudhra. L’entreprise a dit dans le ticket qu’un seul d’entre eux, EM DV TLS CA – G3C, avait été mis en production et qu’elle n’avait délivré aucun certificat final ; personne ne l’a vérifié de façon indépendante.

L’analyse des causes d’eMudhra reste ouverte, et Mozilla n’a pas vérifié ce qu’elle affirme sur les autres séries. Les prochains points à surveiller sont les versions de Node.js et de Bun avec une liste de confiance à jour, le paquet FreeBSD et la migration des quelque 30 000 certificats hors de la racine emSign retirée.