Clés devinables chez eMudhra : les navigateurs sont protégés, mais curl, Python et les conteneurs doivent mettre à jour leurs certificats

Entre le 17 et le 20 octobre 2026, Google, Mozilla, Apple puis Microsoft ont bloqué huit certificats intermédiaires de l’autorité de certification indienne eMudhra, qui se targue d’avoir délivré plus de 60 millions de certificats numériques. Leurs clés privées, censées être impossibles à deviner, se retrouvaient en quelques essais. Les navigateurs à jour sont protégés. Le risque se déplace vers les outils qui gèrent eux-mêmes leur liste d’autorités de confiance : curl, Python, Node, les images de conteneurs et les appareils que plus personne ne met à jour.

Un rappel s’impose pour mesurer l’enjeu. Quand un navigateur ouvre un site en HTTPS, il vérifie que le certificat du site a été signé par une autorité de certification à laquelle il fait confiance. Ces autorités ne signent pas directement avec leur certificat racine, gardé à l’abri : elles passent par des certificats intermédiaires. Celui qui détient la clé privée d’un intermédiaire peut donc, comme le résume Cloudflare, fabriquer un faux certificat pour n’importe quel domaine et se faire passer pour le serveur. Selon Help Net Security, les huit clés compromises proviennent d’un lot de 24 intermédiaires générés par eMudhra le 30 avril 2025 ; d’après Next, six d’entre eux délivraient des certificats TLS, le protocole qui chiffre les connexions HTTPS.

L’une des clés privées de l’autorité de certification eMudhra valait tout simplement le chiffre 4.

Des clés retrouvées en 255 essais

Le défaut tient en une ligne. Le chercheur en cryptographie Scott Helme a analysé le problème sur son blog, et Next l’explique simplement : seul le dernier octet de chaque clé privée était réellement utile, les 47 autres ne contenaient que des zéros. Un octet ne pouvant prendre qu’un nombre très limité de valeurs, retrouver une clé demande au maximum 255 essais ; Scott Helme écrit que l’opération lui a pris moins d’une seconde. Il ajoute qu’une simple requête adressée à un agent d’intelligence artificielle lui a suffi pour retrouver les clés privées de l’autorité. Aucune attaque sophistiquée n’était donc nécessaire pour qui avait l’idée de regarder.

Des navigateurs qui réagissent vite

Le signalement remonte au samedi 17 octobre, selon Scott Helme, qui écrit qu’un chercheur en sécurité a alerté ce jour-là Apple, Google, Microsoft, Mozilla et eMudhra ; Help Net Security nomme ce chercheur Wayne. eMudhra date pour sa part ce signalement du 18 octobre 2026 : les deux versions divergent d’un jour. Mozilla a bloqué les certificats dans Firefox moins de trois heures après avoir été prévenue, grâce à OneCRL, sa liste de révocation transmise aux navigateurs. Chrome a réagi le même jour, Apple a suivi le 19 octobre et Microsoft le 20. Mozilla a ensuite retiré sa confiance à la racine d’eMudhra qui avait signé ces intermédiaires, et Scott Helme indique que Chrome confirme son retrait dans la version 43 de son magasin de racines.

Pour les internautes, le risque d’interception paraît donc faible. Chrome applique par défaut la Certificate Transparency, un système de journaux publics où chaque certificat émis doit être consigné ; or, selon Next, aucun certificat TLS lié aux six intermédiaires concernés n’y avait été enregistré. L’équipe de Chrome, citée par Next, estime qu’aucun certificat frauduleux émis par ces autorités n’aurait pu être considéré comme fiable par défaut. De son côté, Cloudflare indique avoir été informé le 19 octobre 2026 et n’avoir identifié aucune exploitation active de la faille sur ses services. L’entreprise a néanmoins publié des mises à jour de ses applications WARP et 1.1.1.1.

Hors navigateur, le risque demeure

Le problème se situe en dehors des navigateurs. Une foule d’outils, comme curl, Python, Node, Go, Java, git ou les gestionnaires de paquets, s’appuient sur une liste d’autorités enregistrée sur la machine. Selon Scott Helme, ces clients ne vérifient pas la révocation par défaut et ne consultent pas non plus la Certificate Transparency : tant que leur liste n’est pas mise à jour, ils acceptent un certificat forgé avec l’une des clés. Pour le démontrer, le chercheur a fabriqué un certificat pour api.stripe.com, l’interface de paiement en ligne de Stripe ; d’après Next, curl, Python et Node l’ont accepté avec leurs réglages par défaut, sur toutes les machines Linux et macOS testées.

La difficulté tient aussi à la durée. Reste en effet le matériel qui ne peut pas être mis à jour, des objets connectés par exemple : s’il embarque une liste d’autorités figée, il continuera de faire confiance à ces certificats jusqu’à leur expiration, en juillet 2039, selon Next. Scott Helme le formule sans détour en parlant de listes gelées jusqu’en 2039. Les organisations qui s’appuyaient sur ces certificats devront probablement, selon The Register, fouiller leurs environnements pour savoir si elles dépendent de certificats signés par eMudhra. Cloudflare recommande de son côté d’examiner les images de conteneurs et les dépendances des applications.

eMudhra invoque une erreur de manipulation

Depuis le 20 octobre, eMudhra explique dans ses communiqués enquêter sur l’incident. Selon l’autorité, un seul des huit intermédiaires était déployé en production, aucun certificat n’avait été émis à partir d’eux, son infrastructure n’a pas été compromise et aucune donnée n’a fuité ; elle dit les avoir tous révoqués le lendemain du signalement et affirme que les clés privées de ses racines ne sont pas touchées. D’après Next, eMudhra attribue l’incident à une étape de manipulation qui aurait généré un deuxième ensemble de clés, plus faibles, en plus des clés originales. Help Net Security rapporte qu’elle évoque un script défaillant utilisé lors de la cérémonie de génération des clés et reconnaît des erreurs humaines à plusieurs étapes. L’autorité écrit toutefois ne pas avoir encore confirmé la cause exacte.

L’impact n’est pourtant pas nul. Toujours selon eMudhra, le retrait de confiance de sa racine touche un écosystème client aux États-Unis, et l’autorité estime, d’après Help Net Security, qu’environ 30 000 certificats de clients doivent être remplacés. Côté logiciels, des correctifs ont été publiés, comme le liste The Hacker News cité par Next, pour Go, pour la bibliothèque Network Security Services, pour le paquet Python certifi, pour Homebrew ou encore pour la bibliothèque Rust webpki-roots. Un site collectif, tenu par des membres de la communauté, recense les logiciels déjà corrigés et demande de mettre à jour navigateurs et systèmes d’exploitation au plus vite.

Sur un serveur ou un poste Linux, la parade est simple mais doit être menée jusqu’au bout. Il faut installer la mise à jour du paquet ca-certificates dès que la distribution la publie ; en attendant, le site communautaire indique que les utilisateurs avertis peuvent retirer eux-mêmes leur confiance aux racines concernées. Il faut ensuite mettre à jour les dépendances qui embarquent leur propre liste, comme certifi en Python, puis reconstruire les images de conteneurs une fois que les images de base ont intégré le changement, comme le recommande Scott Helme. Cloudflare conseille aussi d’examiner l’arbre des dépendances, certaines listes arrivant par des dépendances indirectes, et insiste : une erreur de certificat ne doit jamais se régler en désactivant la vérification.

Pour les TPE, les PME et les particuliers, la leçon dépasse eMudhra. Le cadenas du navigateur repose sur une chaîne de confiance dont le maillon faible peut se trouver à l’autre bout du monde, chez une autorité dont on n’a jamais entendu parler. Ici, la transparence des journaux de certificats et la rapidité des navigateurs ont limité les dégâts ; le reste dépend de chacun. Tenir à jour son système, son navigateur et ses logiciels, y compris sur le petit serveur ou le NAS installé dans un coin, reste la meilleure protection. Si vous ne savez pas par où commencer pour vérifier vos machines, nous pouvons vous aider à faire le point dans le cadre de notre accompagnement bénévole et gratuit, dans la mesure de nos disponibilités.