veilletech.fr
21 oct. Feed du jour
#01 SÉCURITÉ Faille

eMudhra : huit clés d'AC compromises, mettez à jour

Mettre à jour ne suffit pas : testez le chemin TLS réel.

Les clés privées de huit certificats intermédiaires d'eMudhra (six TLS, deux de signature de code) sont compromises : qui les détient peut émettre un certificat accepté pour n'importe quel site. Les navigateurs ont bloqué ces certificats à distance, mais les clients Go, Python, les images de conteneur et tout magasin de confiance embarqué doivent être mis à jour puis redémarrés. Ne résolvez surtout pas les erreurs de certificat qui en découlent en coupant la vérification.

4 min de lectureintermédiairevidéo 1:17
Partager
Sommaire6 sections
  1. Ce qui se passe
  2. Ce qui est déjà protégé
  3. Ce qui ne l'est pas : votre code
  4. Comment s'y prendre
  5. Ce qu'on ne sait pas
  6. À retenir

Ce qui se passe

Le samedi 17 octobre 2026 à 20:06 UTC, Mozilla reçoit un signalement : les clés privées de huit certificats intermédiaires de l'autorité indienne eMudhra (marque emSign) sont compromises. Cloudflare précise que ces clés sont faibles. Qui les détient peut fabriquer un certificat valide pour n'importe quel domaine, puis se faire passer pour le serveur visé afin d'écouter ou de modifier le trafic. Selon Simon Willison, ces intermédiaires se rattachent à des racines reconnues par les programmes de Mozilla, Microsoft, Apple et Chrome.

La liste publiée par Go ne donne que des empreintes SHA-256 ; un commentateur de l'issue les a rapprochées de certificats eMudhra, et The Hacker News précise ne pas l'avoir vérifié lui-même. D'après ce rapprochement :

Ce qui est déjà protégé

Firefox a bloqué les certificats par OneCRL, sa liste de révocation centrale, le jour même à 22:59 UTC, soit moins de trois heures après le signalement, sans mise à jour ni redémarrage pour les configurations standard. Le 20 octobre sortent Firefox 158.0.1, ESR 115.43.1 et ESR 153.5.1 pour les réglages particuliers, et NSS 3.131.1 retire la racine qui signait ces intermédiaires, au profit des applications qui reprennent le magasin de Mozilla sans recevoir OneCRL.

Cloudflare dit avoir appris l'incident le 19 octobre vers 17:00 UTC, avoir déployé ses protections CDN et Zero Trust côté serveur le 20 à 19:20 UTC et n'avoir constaté aucune exploitation sur ses services. Versions clientes à installer : Cloudflare One / WARP Android 2.5.6, iOS 1.12.16, Windows, macOS et Linux 2026.8.2115.0 ; application 1.1.1.1 Android 6.38.10, iOS 6.31.7 ; cloudflared 2026.10.2.

Ce qui ne l'est pas : votre code

Un navigateur a un interrupteur à distance, pas votre service. Go, lui, bloque par une version : Go 1.27.3 et Go 1.26.10 (20 octobre, voie URGENT) refusent toute chaîne qui passe par l'une des huit clés, y compris une copie croisée, car le filtre compare la clé publique. L'erreur est x509: no valid chains built. Il n'existe aucun réglage pour le couper, Go 1.25 et antérieurs n'ont plus de correctif, et un programme déjà compilé garde l'ancien comportement tant qu'on ne le reconstruit pas. Côté Python, Simon Willison signale uv 0.13.4, pip 26.2.2 et certifi 2026.10.19.

Le conseil de Cloudflare tient en une ligne : regarder sous le SDK. Le comportement de confiance peut venir de la bibliothèque HTTP, du runtime, du système ou d'un magasin personnalisé, et mettre à jour le SDK ne le change pas forcément.

Comment s'y prendre

  1. Mettre à jour ca-certificates (distributions Linux), puis reconstruire et redéployer les images de conteneur.
  2. Passer Go en 1.27.3 ou 1.26.10 et recompiler les binaires.
  3. Mettre à jour pip, uv et certifi dans vos environnements Python.
  4. Recharger ou redémarrer les services pour qu'ils relisent leur magasin.
  5. Tester le vrai chemin TLS de chaque application sur emudhra.we-have-a-problem.com, le site de test de Dennis Jackson (Mozilla). Un test réussi dans un navigateur ne prouve rien pour un service d'arrière-plan, ni un curl si l'application utilise un autre vérificateur.
  6. Si des erreurs de certificat apparaissent ensuite, ne pas désactiver la vérification : cela supprimerait la protection que ces mises à jour rétablissent.

Clients Cloudflare : revoir les magasins de confiance mTLS et les certificats d'origine personnalisés en mode Full (strict) ou Strict.

Ce qu'on ne sait pas

Ce qui s'est passé chez eMudhra n'est pas public. Le ticket Mozilla correspondant n'est pas ouvert au public, Go n'a pas nommé l'autorité, et The Hacker News n'avait trouvé aucune déclaration d'eMudhra au 20 octobre. Le filtre de Go s'applique aussi quand un programme fournit ses propres racines : un déploiement privé qui fait volontairement confiance à l'une de ces clés échouera, et Go n'a pas dit si c'est voulu.

Source : Cloudflare, 20 octobre 2026. Source en anglais. Compléments : Mozilla, The Hacker News (Go), Simon Willison (versions Python).