Compromission de la CA eMudhra : Chrome retire emSign ECC Root CA - G3 le 27 octobre

En bref

• Un chercheur connu sous le nom de Wayne a montré le 17 octobre 2026 que n'importe qui pouvait calculer les clés privées de huit certificats de CA intermédiaires eMudhra à partir des certificats publics. Il a signé un message avec chaque clé récupérée pour le prouver. eMudhra incrimine une étape défectueuse d'enveloppement de clés lors de sa cérémonie du 30 avril 2025. Les huit valeurs sont des entiers inférieurs à 256 ; Scott Helme les a récupérées sur son ordinateur portable en moins d'une seconde.
• Quiconque détient la clé d'une CA intermédiaire peut émettre un certificat valide pour n'importe quel domaine, ce qui permet une usurpation indétectable de sites et de services pour les clients qui lui font confiance. Chrome (CRLSets) et Firefox (OneCRL) ont bloqué les intermédiaires le 17 octobre, Apple à partir du 19 octobre selon son bulletin, et Microsoft le 20 octobre. Aucun certificat issu des six intermédiaires TLS n'a jamais été inscrit dans les journaux Certificate Transparency ; aucun n'a donc atteint un navigateur imposant CT.
• L'exposition concerne tous les clients qui n'imposent pas CT et n'utilisent pas les informations de révocation : curl et d'autres outils en ligne de commande, les environnements d'exécution et les applications qui embarquent leurs propres ensembles de CA, les applications Electron comme Slack et Discord construites sur des versions non corrigées d'Electron, ainsi que les objets connectés et les appareils embarqués. Go, Node.js, Python, certifi, Electron, les principales distributions et de nombreux fournisseurs ont publié des mises à jour ou des listes de refus de clés.
• Si vous exploitez un site dont le certificat remonte à emSign ECC Root CA - G3, Chrome retire cette racine dans la version 43 de son Root Store, qui doit parvenir aux appareils le matin du 27 octobre, heure du Pacifique. Google demande d'obtenir et d'installer immédiatement un certificat issu d'une autre hiérarchie. Environ 30 800 certificats non expirés remontent à cette racine, dont 99.9 pour cent ont été émis via InCommon.

Suis-je concerné ?

Deux groupes sont concernés : les clients qui font encore confiance à emSign ECC Root CA - G3 ou aux intermédiaires compromis sans vérifier CT ni la révocation, et les exploitants de sites dont les certificats remontent à cette racine. Vérifiez les deux aspects.

Certificate Transparency (CT) est un système de journaux publics, accessibles uniquement en ajout, qui enregistrent les certificats TLS émis. Un navigateur imposant CT ne fait confiance à un certificat que s'il contient une preuve de son inscription dans un journal.

En tant que client (quelqu'un peut-il intercepter mes connexions ?), vous êtes concerné si toutes les conditions suivantes sont réunies :

• Le logiciel vérifie TLS à partir d'un magasin de confiance système ou embarqué qui contient encore emSign ECC Root CA - G3 ou accepte les intermédiaires compromis.
• Il n'impose pas Certificate Transparency, ce qui exclut les navigateurs (Chrome, Edge, Firefox, Safari), mais pas curl, la plupart des environnements d'exécution, la plupart des applications Electron et la plupart des clients embarqués.
• Il n'utilise pas les blocages de révocation diffusés (OneCRL, CRLite, CRLSets) qui protègent déjà les navigateurs.

Testez directement le client avec les hôtes de vérification publiés par le site de l'incident. Une erreur de certificat signifie que le client est protégé. Une connexion réussie signifie qu'il fait encore confiance aux intermédiaires compromis ; une réussite sur les hôtes « noct » signifie aussi qu'il n'impose pas CT.

curl ne vérifie jamais Certificate Transparency ; il réussit donc à se connecter aux hôtes « noct » dès lors qu'il fait confiance à la chaîne. Pour tester l'application de CT, connectez-vous à ces hôtes avec le client à vérifier :

curl https://dv-g3b-emudhra.we-have-a-problem.com/
curl https://dv-g3b-aaa-emudhra.we-have-a-problem.com/
curl https://dv-g3b-noct-emudhra.we-have-a-problem.com/        # chain without SCTs; curl does not check CT
curl https://dv-g3b-aaa-noct-emudhra.we-have-a-problem.com/

En tant qu'exploitant de serveur (mon site va-t-il cesser de fonctionner ?), vous êtes concerné si l'un des certificats que vous servez remonte à emSign ECC Root CA - G3. Environ 30 800 certificats non expirés étaient dans ce cas au 21 octobre, selon le décompte des journaux CT effectué par Chrome. 99.9 pour cent avaient été émis via InCommon, le service de certificats qu'Internet2 exploite pour l'enseignement supérieur. InCommon a migré vers la plateforme CertiNext d'eMudhra entre avril et juillet 2026.

Deux de ces CVE portent un score CVSS attribué par l'organisation qui les a assignées : CVE-2026-115557 est critique à 9.4 (CVSS 4.0, Python Software Foundation) et CVE-2026-114820 est critique à 9.1 (CVSS 3.1, Oracle). La fiche CVE-2026-111943 de Go n'a pas de score. Mozilla n'a pas non plus attribué de score à CVE-2026-113470 (Firefox) ; l'enrichissement de la fiche par CISA la classe moyenne à 5.4 (CVSS 3.1).

Le site de l'incident suit des dizaines d'autres logiciels, dont Bun 1.4.4, Deno 2.9.8, Docker Desktop 4.96.2, Git for Windows 2.56.0.3, VS Code 1.143.1, GitHub CLI 2.102.1, conda 26.9.4, pip 26.2.2 et mitmproxy 12.3 ; LibreOffice, Godot, certbot et containerd étaient encore en attente au 27 octobre.

Les outils qui embarquent leur propre Node n'héritent du correctif qu'après passage à un environnement d'exécution corrigé. Les versions de mongosh antérieures à 2.14.0 vérifient les certificats avec le magasin de confiance de l'environnement Node hôte, tandis que la version 2.14.0, publiée le 23 octobre 2026, embarque Node 24.22.1, qui contient la liste de blocage des clés.

Comment corriger le problème ?

Mettez à jour tous les navigateurs et clients hors navigateur, puis remplacez avant le 27 octobre tout certificat remontant à emSign ECC Root CA - G3. En tant qu'exploitant de clients, procédez dans cet ordre :

1. Les navigateurs et systèmes d'exploitation se mettent à jour automatiquement ; confirmez qu'ils sont à jour, car les blocages ont été diffusés par les CRLSets de Chrome (17 octobre), OneCRL de Firefox (17 octobre), les services Google Play d'Android (19 octobre), les mises à jour automatiques des listes de confiance d'Apple (à partir du 19 octobre selon son bulletin) et celles de Microsoft (20 octobre).

2. Corrigez chaque client hors navigateur du tableau :

   • Go : recompilez les binaires avec 1.27.3 ou 1.26.10.
   • Node.js : mettez à jour les environnements d'exécution et les applications qui en embarquent un.
   • Python : passez à 3.15.2, 3.14.10, 3.13.18, 3.12.16 ou 3.11.18, les premières versions dont le module ssl contient la liste de refus CVE-2026-115557, ou fixez certifi à 2026.10.19 ou une version ultérieure.
   • Java : installez les builds hors cycle d'Azul ou un autre JDK qui bloque ces clés.
   • Electron : reconstruisez les applications sur 42.11.16 ou une version ultérieure.

   Attention : les versions Python 3.15.1, 3.14.9 et 3.13.17 du 21 octobre ne contiennent pas la liste de refus. Elles embarquent pip 26.2.2 avec sa copie de certifi 2026.10.19, qui protège uniquement les opérations de pip lui-même.

3. Sur les distributions, installez le paquet ca-certificates mis à jour ; sur RHEL 7, où le paquet était en attente, appliquez la solution de contournement documentée par Red Hat pour bloquer les certificats dans le magasin de confiance.

Sur macOS en particulier, curl et git en ligne de commande, ainsi que Python intégré, vérifient les certificats avec /etc/ssl/cert.pem sans contrôler la révocation. Le bulletin Apple 149555 indique que la plateforme bloque les douze certificats intermédiaires depuis le 19 octobre et la racine depuis le 23 octobre, et que le correctif de /etc/ssl/cert.pem, le fichier consulté par ces outils, « sera disponible dans une future mise à jour logicielle ».

D'ici là, retirez emSign ECC Root CA - G3 de ce fichier avec le script de suppression publié par le site de l'incident. Une seconde étape retire aussi la racine AAA Certificate Services de Sectigo pour bloquer les six copies signées en croisé ; elle avertit que retirer AAA peut casser des sites sans rapport avec l'incident et qu'une mise à jour de macOS peut restaurer le fichier.

Pour un exploitant de site utilisant un certificat sous emSign ECC Root CA - G3, il n'existe pas de solution de contournement : le Chrome Root Program de Google exige que les exploitants « obtiennent et installent immédiatement un nouveau certificat TLS provenant d'une autre hiérarchie PKI incluse dans le Chrome Root Store », avant que le retrait de la racine ne parvienne aux appareils le matin du 27 octobre, heure du Pacifique.

Chrome a également averti que les clients ACME standard ne remplacent pas les certificats hors de leur fenêtre de renouvellement, sauf s'ils prennent en charge ACME Renewal Information (ARI) ou si quelqu'un intervient manuellement ; eMudhra estime qu'environ 30 000 certificats doivent migrer, dont environ 97 pour cent ont été émis par ACME. Des universités ont signalé une voie pratique : les certificats RSA InCommon sous la racine G1 non affectée d'eMudhra fonctionnent encore aujourd'hui, et Let's Encrypt est l'alternative courante.

Quelle est la cause racine ?

La clé privée d'une CA intermédiaire doit être un nombre aléatoire imprévisible ; la cérémonie de clés d'eMudhra a produit, en plus des clés robustes prévues, un second ensemble si prévisible que les certificats publics suffisent à le révéler.

Les huit intermédiaires, six pour TLS (EM DV, EM OV et EM EV TLS CA dans les variantes G3B et G3C) et deux pour la signature de code (EM OV CS CA G3B et G3C), ont été créés sous emSign ECC Root CA - G3 lors d'une cérémonie de génération de clés le 30 avril 2025, sur des modules matériels de sécurité certifiés FIPS 140-2 Level 3.

Dans sa déclaration sur l'incident, eMudhra a indiqué qu'« une étape d'enveloppement/désenveloppement de clé a produit un second ensemble de clés faibles en plus des clés robustes d'origine ». L'enveloppement conditionne une clé pour son transfert, et le désenveloppement l'extrait ensuite. eMudhra a ajouté que « les clés faibles sont celles qui ont été publiées dans les magasins de racines des navigateurs ».

Le site de l'incident énonce clairement la conséquence : « Les clés privées des certificats intermédiaires ont été générées incorrectement par la CA. Cela signifie que n'importe qui peut les récupérer à partir des certificats. » Scott Helme l'a vérifié en pratique, en récupérant les huit clés à partir des certificats publics en moins d'une seconde sur son ordinateur portable.

L'une des huit valeurs est le nombre 4 ; les autres sont également des entiers inférieurs à 256.

Deux faits aggravants sont apparus ensuite.

En 2025, eMudhra avait publié des CRL invalides pour six de ces mêmes intermédiaires et déclaré les avoir corrigées en « régénérant les CRL avec la clé privée appropriée associée à chaque CA intermédiaire ». Le 19 octobre 2026, l'entreprise a indiqué à Mozilla que ces listes avaient en réalité été « resignées avec des clés défectueuses », les mêmes clés faibles. Chrome a déclaré que cela « soulève de sérieuses inquiétudes concernant la transparence d'eMudhra et sa gestion des incidents ».

Le 14 octobre 2026, eMudhra a publié une CRL pour emSign Root TLS CA - G1 dont la signature ne peut pas être vérifiée avec la clé de cette CA. Un participant à un rapport de bug Mozilla a estimé qu'elle avait été signée avec la clé d'un certificat OCSP : « un cas d'utilisation de la mauvaise clé de signature, plutôt qu'une preuve d'une autre clé faible ».

Au 22 octobre, eMudhra n'avait pas répondu aux douze questions de Chrome sur ces points.

Comment la faille est-elle exploitée ?

L'exploitation est mécanique : recalculer l'une des huit clés privées à partir du certificat public, falsifier un certificat terminal pour le domaine ciblé, puis intercepter la connexion d'un client qui omet les vérifications CT et de révocation. Aucune exploitation n'a été observée dans la nature. Le chemin d'attaque contre un client affecté est le suivant :

1. L'attaquant calcule l'une des huit clés privées à partir du certificat intermédiaire public, une étape qui prend moins d'une seconde sur un ordinateur portable.
2. Il émet un certificat pour n'importe quel domaine qu'il veut usurper, signé par cet intermédiaire, et le présente depuis une position permettant d'intercepter les connexions de la victime ou d'y répondre : point d'accès malveillant, interception BGP ou DNS, hôte intranet malveillant.
3. Le client de la victime construit une chaîne allant du certificat terminal falsifié, via l'intermédiaire, jusqu'à une racine de confiance : emSign ECC Root CA - G3 dans son ensemble de certificats, ou AAA Certificate Services de Sectigo via la copie signée en croisé de l'intermédiaire.
4. La connexion est acceptée si le client n'impose pas Certificate Transparency et n'a pas reçu les blocages de révocation ou un ensemble de certificats mis à jour. Imposer CT obligerait l'attaquant à inscrire publiquement le certificat falsifié dans un journal, où il pourrait être repéré. Les navigateurs ne remplissent aucune de ces deux conditions d'exposition et sont protégés ; la plupart des outils en ligne de commande, environnements embarqués et clients intégrés omettaient historiquement ces deux vérifications et restaient exposés jusqu'à leur mise à jour.

Le fait atténuant décisif est qu'aucun certificat remontant aux six intermédiaires TLS n'a jamais été inscrit dans Certificate Transparency avant la mise en place des blocages. Les navigateurs imposant CT exigent un certificat journalisé ; aucun certificat falsifié issu de ces intermédiaires n'a donc atteint Chrome, Edge, Firefox ou Safari. Les journaux CT ne permettent pas de savoir si quelqu'un a utilisé les clés contre des clients sans CT, et le site de l'incident indique que cela reste inconnu.

Quel est le déroulement de l'attaque ?

Le déroulement est linéaire : calculer la clé à partir du certificat public, falsifier un certificat terminal pour le domaine ciblé, se placer sur le chemin de la connexion et laisser un client sans CT valider la chaîne.

Que peut faire un attaquant ?

Face à un client non corrigé sans CT, l'attaquant peut usurper n'importe quel site ou service auquel le client se connecte en TLS : collecter des identifiants, servir un logiciel malveillant via un flux de mise à jour, ou rediriger le trafic d'API, avec un certificat auquel le client fait pleinement confiance. Les conditions sont les suivantes :

• Une position réseau permettant d'intercepter le trafic de la victime ou d'y répondre. La victime n'a rien à faire d'autre que se connecter.
• Un client qui fait confiance à l'une des racines ou signatures croisées affectées, n'impose pas CT et n'a pas reçu de blocage. Cette combinaison exclut les navigateurs actuels et inclut les outils basés sur curl, les environnements et applications dotés de leurs propres ensembles de certificats, les applications Electron construites avant les versions corrigées et les appareils IoT.
• Rien d'autre. Les clés n'ont jamais été volées, car cela n'était pas nécessaire : elles étaient, de fait, publiées dans les certificats eux-mêmes.

Les deux intermédiaires de signature de code étendent la surface théorique au code signé sur les plateformes qui leur font confiance, même si le vérificateur TLS de Chrome ne construit pas de chemin via un intermédiaire réservé à la signature de code, et qu'aucun abus de signature de code n'a été signalé. Certificate Transparency, dont les journaux confirment qu'aucun faux certificat TLS n'a atteint les navigateurs, ne couvre que les certificats TLS ; il ne fournit donc aucune trace comparable pour le code signé.

Pourquoi le correctif fonctionne-t-il ?

Le correctif fonctionne en fermant tous les chemins possibles d'une chaîne falsifiée : les listes de refus rejettent les clés faibles elles-mêmes, le retrait des ensembles de certificats coupe la racine, et la révocation diffusée bloque les intermédiaires dans les navigateurs. Chaque mécanisme a une couverture différente :

• Listes de refus de clés, la protection la plus forte : crypto/x509 de Go, Node.js et le module ssl de Python rejettent tout certificat portant l'une des huit clés, y compris les copies signées en croisé par Sectigo. Python compare le hachage SHA-256 du SubjectPublicKeyInfo de chaque certificat, quelle que soit la politique SSLContext, et la liste de refus de Go ne peut pas être désactivée.
• Retrait des ensembles de certificats, la couverture la plus large : certifi, webpki-roots, Debian, Ubuntu, Fedora, RHEL et d'autres paquets de distributions retirent entièrement emSign ECC Root CA - G3, coupant tous les certificats sous cette racine, légitimes ou falsifiés.
• Révocation diffusée, la réponse la plus rapide : CRLSets, OneCRL et les mises à jour des listes de confiance de Microsoft bloquent les intermédiaires pour les navigateurs sans mise à jour logicielle.

Les limites comptent. Une liste de refus n'aide qu'une fois le logiciel reconstruit ou mis à jour ; les binaires Go doivent être recompilés.

Le retrait d'un ensemble coupe aussi les certificats légitimes sous la racine, ce dont Mozilla, Canonical et Red Hat ont tous averti. C'est précisément ce qui rendra inutilisables les quelque 30 800 certificats actifs lorsque Chrome retirera la racine elle-même le 27 octobre.

La protection par révocation ne couvre que les clients qui utilisent réellement les données de révocation, ce que les clients hors navigateur concernés ne font généralement pas. Cette lacune explique l'existence même des listes de refus dans Go, Node.js et Python. Comme l'a formulé Filippo Valsorda dans le ticket Go :

« Les magasins de racines Linux sont maintenus de façon trop incohérente pour que la révocation parvienne aux applications ; les clés sont donc rejetées dans le code. »

Comment vérifier si j'ai été compromis ?

Aucune méthode publiée ne permet de détecter une utilisation abusive passée des clés contre des clients sans CT, et le site de l'incident indique qu'on ignore si quelqu'un a exploité la génération défectueuse avant le 17 octobre. Voici ce que vous pouvez vérifier :

• Côté client, testez les quatre hôtes de vérification de la section « Suis-je concerné ? » dans chaque environnement important, y compris dans les conteneurs et sur les machines de build. Le site publie aussi chains.zip, contenant chaque chaîne servie au format PEM pour une vérification hors ligne avec OpenSSL, ainsi que des statistiques de réussite par agent utilisateur.
• Côté serveur, inventoriez les certificats remontant à emSign ECC Root CA - G3 ou emSign Root TLS CA - G3 à l'aide de l'outil de surveillance des journaux CT de votre choix ; tout certificat trouvé doit être remplacé avant le 27 octobre, pas simplement surveillé.
• Côté gestion des certificats, vérifiez si votre configuration ACME prend en charge ACME Renewal Information (RFC 9773) ; sans cela, les clients ne remplacent pas les certificats hors de la fenêtre de renouvellement. C'est ainsi qu'un certificat expirant en novembre peut tout de même cesser de fonctionner le 27 octobre.

Chronologie

• 2025-04-30 : la cérémonie de génération de clés d'eMudhra crée les huit intermédiaires, produisant les clés faibles en plus des clés robustes.
• 2025 : eMudhra publie des CRL invalides pour six des mêmes intermédiaires, reconnaissant ensuite qu'elles ont été « resignées avec des clés défectueuses ».
• 2026-10-17 : Wayne signale les clés récupérables aux programmes de racines avec des preuves signées ; Chrome diffuse un blocage CRLSet avant 19:45 UTC et Mozilla pousse OneCRL avant 22:59 UTC.
• 2026-10-19 : les magasins de confiance en aval sont informés ; Android reçoit son blocage via les services Google Play vers 22:00 UTC ; Apple commence à bloquer les douze certificats intermédiaires sur ses appareils selon son bulletin ; eMudhra indique à Mozilla que les CRL de 2025 ont été resignées avec les clés défectueuses.
• 2026-10-20 : Mozilla et Google communiquent ; Go publie 1.27.3 et 1.26.10 ; certifi publie 2026.10.19 ; Firefox 158.0.1 et ESR embarquent le blocage ; les blocages Microsoft arrivent ; Mozilla retire la racine de NSS.
• 2026-10-21 : eMudhra divulgue le défaut de la cérémonie dans un communiqué à la BSE ; CERT-In publie CIAD-2026-0050 ; Red Hat publie RHSB-2026-012 ; Node.js diffuse sa liste de blocage ; Azul publie ses builds Zulu et Zing hors cycle bloquant les huit intermédiaires ; l'action eMudhra chute de 20 pour cent à Mumbai.
• 2026-10-22 : le conseil d'administration d'eMudhra décide de quitter l'activité mondiale SSL/TLS (environ 1 pour cent du chiffre d'affaires) ; les douze questions de Chrome à eMudhra restent sans réponse publique.
• 2026-10-23 : Apple commence aussi à bloquer emSign ECC Root CA - G3, selon son bulletin.
• 2026-10-24 : Python annonce la liste de refus du module ssl sous CVE-2026-115557 et la rétroporte sur les branches de maintenance 3.11 à 3.15.
• 2026-10-25 : Python publie 3.15.2, 3.14.10, 3.13.18, 3.12.16 et 3.11.18, les premières versions intégrant la liste de refus ; certifi 2026.10.23 devient la version actuelle.
• 2026-10-27 : la version 43 du Chrome Root Store retire emSign ECC Root CA - G3, avec une arrivée attendue sur les appareils le matin du 27 octobre, heure du Pacifique. La mise à jour macOS d'Apple couvrant les outils en ligne de commande n'avait toujours pas été publiée au matin du 27 octobre, et son index des mises à jour de sécurité ne comportait aucune entrée pour cet incident ; les étapes manuelles sur /etc/ssl/cert.pem ci-dessous restent donc le correctif pour curl, git et Python intégrés.

FAQ

Puis-je utiliser mon navigateur en sécurité maintenant ?

Oui. Chrome, Edge, Firefox et Safari imposent Certificate Transparency, et aucun certificat issu des six intermédiaires TLS n'a jamais été journalisé dans CT. Aucun faux certificat de ces intermédiaires n'a donc atteint un navigateur, même avant l'arrivée des blocages de révocation. Les blocages depuis le 17 octobre ferment la porte à tout certificat qu'un navigateur pourrait accepter sans contrôle CT.

J'ai mis à jour macOS. Pourquoi curl est-il encore vulnérable ?

Apple a bloqué les douze certificats intermédiaires (chaque intermédiaire TLS sous la racine d'eMudhra et sa copie signée en croisé par Sectigo) le 19 octobre, puis la racine le 23 octobre, via les mises à jour automatiques de configuration des certificats. Elles protègent Safari, Mail et les applications utilisant les frameworks réseau et de sécurité d'Apple.

curl, git et Python intégrés vérifient les certificats avec /etc/ssl/cert.pem sans contrôler la révocation. Le bulletin Apple 149555 indique que le correctif à cet endroit « sera disponible dans une future mise à jour logicielle ». D'ici là, retirez la racine du fichier manuellement ou avec le script du site de l'incident ; une mise à jour de macOS peut restaurer le fichier.

Mon site va-t-il réellement cesser de fonctionner le 27 octobre ?

Uniquement si son certificat remonte à emSign ECC Root CA - G3, ce qui était le cas d'environ 30 800 certificats non expirés au 21 octobre. Pour ceux-là, oui : dès que la version 43 du Root Store parvient à un utilisateur de Chrome, la chaîne n'est plus valide. Google demande aux exploitants de remplacer immédiatement le certificat, sans attendre le retrait, et de se rappeler que les clients ACME ne renouvellent pas par anticipation sans prise en charge d'ARI.

eMudhra a-t-il été piraté ?

Aucun système n'a été compromis et aucune clé n'a été volée, ce qui rend cet incident inhabituel. Les clés ont été mal générées, et une clé mal générée est publique de fait : toute personne possédant le certificat pouvait la calculer, sans intrusion. eMudhra affirme que sept des huit intermédiaires n'ont jamais été utilisés en production, et qu'aucun des huit, y compris celui qui l'a été, n'a émis de certificat d'entité finale.

Dois-je aussi retirer la racine Sectigo ?

Uniquement pour les clients que vous ne pouvez pas corriger autrement. Six des huit intermédiaires existent aussi sous forme de signatures croisées sous la racine AAA Certificate Services de Sectigo ; retirer uniquement emSign ECC Root CA - G3 laisse donc ces chemins ouverts. Mais retirer AAA coupe aussi tous les certificats légitimes sous cette racine. C'est pourquoi les mises à jour des distributions qui retirent les deux avertissent aussi des interruptions possibles, et pourquoi les correctifs par liste de refus de clés constituent la meilleure réponse lorsqu'ils existent.

Est-ce la même chose que la mise à jour d'urgence de Go que j'ai installée le 20 octobre ?

Oui. Go a publié 1.27.3 et 1.26.10 ce jour-là sans nommer la CA, bloquant huit hachages de clés dans crypto/x509 via sa procédure URGENT ; ces huit hachages correspondent aux huit certificats. L'équipe sécurité de Go a expliqué avoir laissé les notes de version vagues parce que la faille était triviale à exploiter et qu'elle s'attendait à ce que les détails deviennent publics le jour même.

Repérez les certificats qui cesseront de fonctionner le 27 octobre

Utilisez Ostorlab Attack Surface Discovery pour inventorier les domaines et hôtes exposés à Internet que vous possédez. Vérifiez ensuite si la chaîne de certificats servie par chacun contient emSign ECC Root CA - G3, et remplacez toute correspondance avant que Chrome ne retire la racine le 27 octobre.

Références

• Site de l'incident contenant les preuves, hôtes de vérification, ensemble de chaînes hors ligne et tableau des correctifs, maintenu depuis le 20 octobre 2026 : https://emudhra.we-have-a-problem.com/ (consulté le 27 octobre 2026)
• Bulletin Apple sur les CA intermédiaires eMudhra compromises, 149555 : blocage depuis le 19 octobre, racine depuis le 23 octobre, correctif de /etc/ssl/cert.pem dans une future mise à jour, étapes de suppression manuelle ; index des mises à jour de sécurité Apple, vérifié pour une entrée sur l'incident le matin du 27 octobre 2026 : https://support.apple.com/en-us/149555 et https://support.apple.com/en-us/100100 (consultés le 27 octobre 2026)
• Déclaration d'Azul sur la compromission des CA intermédiaires eMudhra, 22 octobre 2026, avec les builds Zulu et Zing hors cycle du 21 octobre bloquant les huit intermédiaires : https://www.azul.com/newsroom/azul-statement-on-the-emudhra-intermediate-ca-certificates-compromise/ (consultée le 26 octobre 2026)
• Google sur la protection des utilisateurs de Chrome et Android contre les certificats de CA intermédiaires eMudhra compromis, 20 octobre 2026 : https://blog.google/security/protecting-chrome-and-android-users-from-compromised-emudhra-intermediate-ca-certificates/ (consulté le 25 octobre 2026)
• Mozilla sur la protection des utilisateurs de Firefox, 20 octobre 2026 : https://blog.mozilla.org/security/2026/10/20/protecting-firefox-users-following-the-compromise-of-emudhra-intermediate-certificates/ (consulté le 25 octobre 2026)
• Discussions du Chrome Root Program et de la liste de politiques Mozilla citées dans les articles : https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/0R3XLJL6FuE/m/Kp1v6CPuAAAJ (consultées le 25 octobre 2026)
• Communiqué d'eMudhra déposé auprès de la BSE sur le défaut de la cérémonie du 30 avril 2025 : https://www.bseindia.com/xml-data/corpfiling/AttachLive/6be0c423-b335-494b-86f3-54c561c3a5f9.pdf (consulté le 25 octobre 2026)
• Déclaration d'eMudhra sur l'incident de sécurité des certificats : https://emudhra.com/en/post/certificate-security-incident (consultée le 25 octobre 2026)
• Récupération indépendante des clés par Scott Helme, les huit en moins d'une seconde, dont l'une est le nombre 4 : https://scotthelme.co.uk/eight-bits-of-trust-emudhras-ca-keys-cracked-in-milliseconds/ (consultée le 25 octobre 2026)
• The Hacker News sur les huit clés de CA compromises et les correctifs d'urgence de l'écosystème, 20 octobre 2026, mis à jour le 21 octobre : https://thehackernews.com/2026/10/eight-emudhra-ca-keys-compromised.html (consulté le 25 octobre 2026)
• The Hacker News sur la sortie d'eMudhra de l'activité mondiale SSL/TLS, les quelque 30 800 certificats non expirés, la concentration InCommon et le retrait par Chrome le 27 octobre, 22 octobre 2026 : https://thehackernews.com/2026/10/emudhra-to-exit-global-ssltls-business.html (consulté le 25 octobre 2026)
• Versions d'urgence de Go bloquant les huit clés, CVE-2026-111943 : https://groups.google.com/g/golang-announce/c/66pojueaQek et https://cveawg.mitre.org/api/cve/CVE-2026-111943 (consultées le 25 octobre 2026)
• Annonce de la liste de refus du module ssl de Python, CVE-2026-115557, 24 octobre 2026 : https://www.openwall.com/lists/oss-security/2026/10/24/5 et https://cveawg.mitre.org/api/cve/CVE-2026-115557 (consultées le 25 octobre 2026)
• Fiche Firefox CVE-2026-113470, sans score Mozilla et avec l'enrichissement CISA à 5.4, sévérité moyenne : https://cveawg.mitre.org/api/cve/CVE-2026-113470 (consultée le 27 octobre 2026)
• Journaux des versions CPython confirmant la première diffusion de la liste de refus dans 3.15.2, 3.14.10, 3.13.18 et 3.12.16 le 25 octobre, et vue comparative CPython confirmant que v3.11.18, étiquetée le même jour, contient le rétroportage : https://docs.python.org/3.15/whatsnew/changelog.html et https://github.com/python/cpython/compare/af52b41afa4330fb38583db553631baa2f122f90...v3.11.18 (consultés le 26 octobre 2026)
• Alerte Java hors cycle d'Oracle retirant les racines eMudhra, CVE-2026-114820 : https://www.oracle.com/security-alerts/alert-cve-2026-114820.html (consultée le 25 octobre 2026)
• Bulletin certifi GHSA-6q48-6c7w-9gw2 retirant la racine emSign : https://github.com/certifi/python-certifi/security/advisories/GHSA-6q48-6c7w-9gw2 (consulté le 25 octobre 2026)
• Bulletin uv GHSA-hq85-5cpj-mr62 retirant la racine emSign : https://github.com/astral-sh/uv/security/advisories/GHSA-hq85-5cpj-mr62 (consulté le 25 octobre 2026)
• Bulletin Red Hat RHSB-2026-012 avec la solution de contournement pour le magasin de confiance RHEL : https://access.redhat.com/security/vulnerabilities/RHSB-2026-012 (consulté le 25 octobre 2026)
• Bulletin CERT-In CIAD-2026-0050, 21 octobre 2026 : https://www.cert-in.org.in/s2cMainServlet?pageid=PUBVLNOTES02&VLCODE=CIAD-2026-0050 (consulté le 25 octobre 2026)
• Versions corrigées de WARP, des clients 1.1.1.1 et de cloudflared 2026.10.2 de Cloudflare : https://blog.cloudflare.com/emudhra-certificate-compromise (consulté le 25 octobre 2026)
• Version mongosh 2.14.0, 23 octobre 2026, embarquant Node 24.22.1 avec la liste de blocage des clés, alors que les versions précédentes vérifient avec le magasin de confiance de l'environnement Node hôte : https://github.com/mongodb-js/mongosh/releases/tag/v2.14.0 (consultée le 27 octobre 2026)