Huit certificats intermédiaires de l’autorité de certification indienne eMudhra ont été signalés le 17 octobre 2026 avec des clés privées de 3 à 8 bits au lieu des 384 attendus, l’une d’elles valant le nombre 4. Les navigateurs ont bloqué ces certificats en quelques heures, mais le nettoyage des machines Linux, des conteneurs et des objets connectés sera « plus gros que Heartbleed » selon l’ingénieur en cryptographie Filippo Valsorda.
Une clé privée qui valait le nombre 4
Le 17 octobre 2026, vers 18 h UTC, une personne se présentant sous le nom de « Wayne » prévient les équipes des programmes de certificats racine qu’elle détient les clés privées de huit certificats intermédiaires d’eMudhra Limited. Pour le prouver, elle signe avec chacune de ces clés le message « Nous avons un problème ici, Wayne », publié sur un site d’avis informel mis en ligne par Dennis Jackson. Selon Ars Technica, ces clés de type courbe elliptique NIST P-384 auraient dû contenir environ 384 bits d’entropie : elles n’en contenaient que 3 à 8, et le média énumère les valeurs 4, 56, 66, 115, 155, 156, 230 et 237. Heise rapporte le même ordre de grandeur et mentionne l’identifiant CVE-2026-111943.
Ce que permet un seul maillon intermédiaire
Les huit certificats intermédiaires en cause sont contresignés par Sectigo et remontent à des racines reconnues par les programmes de Mozilla, Microsoft, Apple et Chrome, ainsi que par de nombreux magasins de confiance en aval, indique le site d’avis. Quiconque dispose de ces clés peut donc fabriquer des certificats de serveur pour n’importe quel site, certificats que des millions de machines accepteront comme valides. C’est l’ensemble du régime TLS qui est en cause, souligne Ars Technica : il ne vaut que par son maillon le plus faible, ici une autorité dont personne n’avait contrôlé la qualité des clés.
Trois heures chez Mozilla, trois jours chez Microsoft
La réaction des éditeurs de navigateurs a été rapide, mais pas simultanée. Selon le site d’avis, Firefox et Chrome ont bloqué les huit intermédiaires dès le 17 octobre, Mozilla achevant le déploiement de sa liste de révocation OneCRL à 22 h 59 UTC, soit environ trois heures après le signalement d’après heise. Apple a suivi le 19 octobre, Microsoft le 20 octobre, jour où Mozilla a aussi retiré les racines concernées de sa liste de confiance. Au moment où Ars Technica publiait son article, le 20 octobre à 19 h 47 UTC, le navigateur Edge se connectait encore à douze hôtes vulnérables ; un porte-parole de Microsoft a répondu que l’entreprise reviendrait vers le média si elle avait quelque chose à « partager ».
| Acteur | Date du blocage | Mécanisme indiqué par le site d’avis |
|---|---|---|
| Mozilla (Firefox) | 17 octobre 2026, déploiement achevé à 22 h 59 UTC | Liste de révocation OneCRL |
| Chrome | 17 octobre 2026 | CRLSets |
| Apple | 19 octobre 2026 | CRLite |
| Microsoft | 20 octobre 2026 | Non précisé, Edge encore exposé le 20 octobre selon Ars Technica |
« Plus gros que Heartbleed » : la traîne des machines oubliées
Le site d’avis recense plus de vingt logiciels corrigés, dont les paquets ca-certificates d’Ubuntu, le langage Go dans ses versions 1.27.3 et 1.26.10, Python certifi, les projets Rust webpki et Electron, Node.js restant en attente. Filippo Valsorda, mainteneur de la cryptographie de Go, prévient dans Ars Technica : « Ce sera un énorme travail de nettoyage, plus gros que Heartbleed. » Il décrit « une très, très longue traîne : objets connectés, conteneurs Docker, machines Linux oubliées, outils en ligne de commande non maintenus qui embarquent leur propre copie des racines ». Sur l’origine du défaut, Ben Cartwright-Cox, directeur de BGP.tools, avance : « Mon intuition, c’est que c’est du code d’exemple qui a fini en production par accident. »
Aucun abus constaté, mais une interception toujours possible
Deux réserves encadrent l’incident. Aucun signalement, dans les journaux de transparence des certificats, ne fait état de certificats émis avec ces clés : aucun usage malveillant n’est donc attesté. Et exploiter ces certificats suppose une attaque active, l’attaquant devant se placer entre les deux parties pour déchiffrer puis rechiffrer le trafic, capacité en général réservée aux acteurs les mieux dotés, rappelle Ars Technica, sauf pour qui contrôle un réseau local, dans un café, une université ou une entreprise.
Le risque immédiat le plus net concerne les utilisateurs de réseaux privés virtuels, en particulier dans les pays dont le gouvernement est susceptible d’intercepter le trafic. Signal, WhatsApp et WireGuard, qui ne reposent pas sur TLS pour la confidentialité, ne sont pas touchés. Les représentants d’eMudhra n’étaient pas joignables pour répondre aux questions d’Ars Technica. Le site d’avis conseille de mettre à jour navigateurs et systèmes d’exploitation dès que possible et, pour les administrateurs Linux, de retirer la confiance accordée aux racines concernées via les mises à jour de paquets.
