Une erreur de génération de clés chez l’autorité de certification indienne eMudhra a rendu calculables par tous les clés privées de huit certificats intermédiaires reconnus par Chrome, Firefox, Safari et Windows. Les navigateurs ont bloqué ces certificats en quelques heures. Serveurs, conteneurs, applications et outils en ligne de commande demandent une intervention manuelle, et l’exposition passée de ces systèmes reste inconnue.
Une clé privée égale à 4
Le 17 octobre au soir, un chercheur identifié sous le prénom Wayne a signalé aux programmes de racines de Google, Mozilla, Apple et Microsoft que huit certificats intermédiaires émis par eMudhra reposaient sur des clés privées récupérables par n’importe qui. Pour le prouver, il a signé avec chacune des huit clés le message « We have a problem here – Wayne ». Mozilla a retrouvé les clés le soir même, sans connaître la méthode du chercheur, ce qui confirme que la faiblesse est reproductible.
Les clés en cause, de type P-384, étaient de simples entiers inférieurs à 256, au lieu de grands nombres aléatoires. L’une d’elles, attachée au certificat « EM OV TLS CA – G3C », vaut 4. Le chercheur Scott Helme indique avoir recalculé les huit clés à partir des certificats publics en moins d’une seconde. Aucun vol n’a donc été nécessaire : la clé se déduisait du certificat lui-même.
https://emudhra.we-have-a-problem.com/?utm_source=thecode-cybersecurity.beehiiv.com&utm_medium=newsletter&utm_campaign=the-internet-goes-on-high-alert-after-discovery-of-8-compromised-tls-certs&_bhlid=1f10541e7a2a304d4026da488d6319d4393c125e
Six autorités TLS et deux autorités de signature de code
Les huit certificats relèvent des séries G3B (eMudhra BV, Pays-Bas) et G3C (eMudhra Inc, États-Unis). Ils couvrent deux autorités à validation de domaine (DV), deux à validation d’organisation (OV), deux à validation étendue (EV) et deux autorités de signature de code. Les six autorités TLS remontent à la racine « emSign ECC Root CA – G3 ». Chacune existe aussi en copie signée de manière croisée par Sectigo sous sa racine « AAA Certificate Services ».
Une autorité intermédiaire signe les certificats présentés par les sites web. Détenir sa clé privée permet de fabriquer un certificat accepté pour n’importe quel domaine, puis de se faire passer pour un serveur afin d’intercepter ou de modifier le trafic. Pour les deux autorités de signature de code, le risque porte sur la signature de logiciels.
Une erreur de script lors d’une cérémonie de clés
eMudhra attribue l’incident à une erreur dans le script employé lors de la cérémonie de génération de clés du 30 avril 2025. Ce script aurait produit un second jeu de clés faibles, retenu par erreur pour signer les certificats parce que ses libellés ressemblaient à ceux des clés correctement générées. L’entreprise reconnaît plusieurs erreurs humaines, affirme que la plupart des autorités concernées n’ont jamais servi en production et poursuit son enquête sur la cause profonde.
Les clés sont donc restées exploitables depuis avril 2025, soit près de dix-huit mois.
Des navigateurs protégés en quelques heures
Le programme de racines de Chrome a reçu le signalement à 18 h 05 UTC le 17 octobre et a diffusé un blocage par CRLSet dès 19 h 45 UTC. Mozilla a poussé un blocage OneCRL vers Firefox avant minuit UTC. Les navigateurs récupèrent ces listes d’eux-mêmes, sans mise à jour ni redémarrage. Apple a suivi le 19 octobre, Microsoft le 20. eMudhra a révoqué les huit certificats le 18 octobre avec le motif « cACompromise », et Sectigo ses copies croisées le lendemain.
Google affirme qu’aucun certificat de site rattaché aux six autorités TLS ne figurait dans les journaux de Certificate Transparency avant son blocage. Chrome, Firefox, Edge et Safari refusent un certificat absent de ces journaux, si bien que leurs utilisateurs n’ont pas pu être attaqués par ce biais. Google indique aussi avoir contrôlé tous les autres certificats d’autorité de son magasin sans trouver de défaut comparable.
Hors navigateur, une exposition inconnue
Beaucoup de logiciels ne consultent ni les listes de révocation ni les journaux de transparence. Bibliothèques réseau, environnements d’exécution, binaires Go, scripts Python reposant sur le paquet certifi, conteneurs et outils en ligne de commande continuent de faire confiance à une chaîne tant que leur code ou leur magasin de certificats n’a pas changé. Pour ces clients, Mozilla reconnaît ne pas savoir si des attaquants ont exploité la faille. Aucune source ne propose aujourd’hui de moyen de détecter un usage passé des clés en dehors de la recherche dans les journaux de transparence, qui ne couvre que les certificats journalisés.
Le magazine iTnews a constaté que l’outil curl intégré à macOS acceptait encore la chaîne compromise malgré le blocage décidé par Apple, car il lit son propre fichier de certificats sans vérifier la révocation.
Le site de suivi publié par Dennis Jackson, ingénieur en cryptographie chez Mozilla (emudhra.we-have-a-problem.com), permet de tester un navigateur ou un client en ligne de commande et recense les correctifs. Go a publié les versions 1.27.3 et 1.26.10 (CVE-2026-111943), qui imposent de recompiler les programmes. Mozilla a livré NSS 3.131.1 et Firefox 158.0.1. Côté Python, certifi 2026.10.19, pip 26.2.2 et uv 0.13.4 sont disponibles, comme rustls-webpki 0.103.16 et webpki-roots 1.0.10 pour Rust et Electron 44.9.1 pour les applications de bureau. Ubuntu, Debian, Fedora, Arch, Gentoo, Alpine et Chainguard ont mis à jour leurs paquets ca-certificates. Au 21 octobre, Node.js, Bun et FreeBSD restaient en attente.
Les recommandations de Cloudflare, Mozilla et Google
Cloudflare, informé le 19 octobre vers 17 h UTC, a corrigé ses clients WARP et 1.1.1.1 ainsi que son logiciel Tunnel le 20 octobre, et dit n’avoir relevé aucune exploitation sur ses services. L’entreprise estime qu’une large part du travail reste à faire chez ses clients. Elle les invite à vérifier les autorités acceptées par leurs serveurs d’origine, à revoir la liste des autorités utilisées pour valider les certificats clients en TLS mutuel (mTLS) et à contrôler les magasins de certificats embarqués dans leurs images de conteneurs.
Cloudflare prévient aussi les développeurs qu’une mise à jour de kit de développement ne suffit pas toujours, car la vérification peut relever d’une bibliothèque HTTP, de l’environnement d’exécution, du système ou d’une configuration propre. Un test réussi dans un navigateur ou avec curl ne prouve rien pour un service qui s’appuie sur un autre vérificateur. L’entreprise met surtout en garde contre la tentation de faire disparaître les erreurs de connexion en désactivant la vérification des certificats.
Mozilla recommande aux gestionnaires de magasins de certificats de bloquer les huit intermédiaires lorsque leur logiciel le permet, et à défaut de retirer la confiance dans les racines qui les ont signés. Aux utilisateurs, Mozilla demande de mettre à jour navigateurs et systèmes d’exploitation au plus vite. Le site de suivi détaille des contournements pour curl sous macOS, Linux, NetBSD et FreeBSD, réservés aux utilisateurs expérimentés.
La racine emSign ECC G3 retirée
Les navigateurs vont plus loin que le blocage des huit certificats. Mozilla a retiré la racine « emSign ECC Root CA – G3 » de NSS le 20 octobre. Chrome la retirera dans la version 43 de son magasin de racines et réexamine le statut de l’autre racine eMudhra qu’il accepte, « emSign Root CA – G1 », en invoquant la gravité de l’incident.
eMudhra a cessé toute émission sous cette racine et estime à environ 30 000 le nombre de certificats légitimes à migrer. Le retrait de la racine dans NSS, certifi, webpki-roots ou Homebrew coupe aussi l’accès aux serveurs légitimes qui en dépendent, tant que ceux-ci n’ont pas changé de chaîne de certification. Les clients d’eMudhra doivent donc anticiper des erreurs de connexion du côté de leurs propres utilisateurs.
Pour les responsables de traitement
L’incident relève de la sécurité du traitement prévue à l’article 32 du RGPD. Les organisations ont intérêt à inventorier les applications, serveurs, conteneurs et objets connectés qui valident des certificats en dehors d’un navigateur, à appliquer les correctifs disponibles et à garder trace des actions menées. Une notification à la CNIL au titre de l’article 33 ne se poserait que si une interception de données personnelles venait à être établie.
