Compromiso de la CA eMudhra: Chrome retira emSign ECC Root CA - G3 el 27 de octubre

Resumen

• Un investigador conocido como Wayne demostró el 17 de octubre de 2026 que cualquiera puede calcular las claves privadas de ocho certificados de CA intermedias de eMudhra a partir de los certificados públicos, firmando un mensaje con cada clave recuperada como prueba. eMudhra atribuye el problema a un paso defectuoso de encapsulado de claves en su ceremonia de claves del 30 de abril de 2025. Los ocho valores son números enteros inferiores a 256; Scott Helme los recuperó en su portátil en menos de un segundo.
• Cualquiera que posea la clave de una CA intermedia puede emitir un certificado válido para cualquier dominio, lo que permite suplantar sitios web y servicios de forma indetectable para los clientes que confían en ella. Chrome (CRLSets) y Firefox (OneCRL) bloquearon las intermedias el 17 de octubre, Apple desde el 19 de octubre, según su aviso, y Microsoft el 20 de octubre. Nunca se registró en Certificate Transparency ningún certificado de las seis intermedias TLS, por lo que ninguno llegó a un navegador que exigiera CT.
• Están expuestos todos los clientes que no exigen CT ni consultan revocaciones: curl y otras herramientas de línea de comandos, entornos de ejecución de lenguajes y aplicaciones con paquetes de CA propios, aplicaciones Electron como Slack y Discord construidas sobre versiones de Electron sin corregir, y dispositivos IoT e integrados. Go, Node.js, Python, certifi, Electron, las principales distribuciones y muchos proveedores han publicado actualizaciones o listas de claves bloqueadas.
• Si opera un sitio web cuyo certificado encadena a emSign ECC Root CA - G3, Chrome retira esa raíz en la versión 43 de Root Store, que llega a los dispositivos la mañana del 27 de octubre, hora del Pacífico. Google indica que se adquiera e instale inmediatamente un certificado de otra jerarquía. Unos 30.800 certificados sin caducar encadenan a esa raíz, el 99.9 por ciento emitidos a través de InCommon.

¿Estoy afectado?

Hay dos grupos afectados: los clientes que aún confían en emSign ECC Root CA - G3 o en las intermedias comprometidas sin comprobar CT ni revocación, y los operadores de sitios cuyos certificados encadenan a esa raíz. Compruebe ambos.

Certificate Transparency (CT) es el sistema de registros públicos de solo anexado que recoge los certificados TLS emitidos. Un navegador que exige CT solo confía en un certificado si lleva pruebas de que fue registrado.

Como cliente (¿puede alguien interceptar mis conexiones?), está afectado si se cumplen todas estas condiciones:

• El software verifica TLS contra un almacén de confianza del sistema o incluido que aún contiene emSign ECC Root CA - G3 o acepta las intermedias comprometidas.
• No exige Certificate Transparency, lo que excluye a los navegadores (Chrome, Edge, Firefox, Safari), pero no a curl, la mayoría de los entornos de ejecución, la mayoría de las aplicaciones Electron y la mayoría de los clientes integrados.
• No consume los bloqueos de revocación distribuidos (OneCRL, CRLite, CRLSets) que ya protegen a los navegadores.

Pruebe directamente el cliente con los hosts de comprobación publicados en el sitio del incidente. Un error de certificado significa que el cliente está protegido. Una conexión exitosa significa que aún confía en las intermedias comprometidas, y el éxito en los hosts «noct» también significa que no exige CT.

curl nunca comprueba Certificate Transparency, por lo que conecta correctamente a los hosts «noct» siempre que confíe en la cadena. Para comprobar si se exige CT, conéctese a ellos desde el cliente que quiera verificar:

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/

Como operador de servidor (¿dejará de funcionar mi sitio?), está afectado si cualquier certificado que sirve encadena a emSign ECC Root CA - G3. A 21 de octubre, unos 30.800 certificados sin caducar lo hacían, según el recuento de Chrome en los registros CT. El 99.9 por ciento se emitió a través de InCommon, el servicio de certificados de Internet2 para educación superior. InCommon migró a la plataforma CertiNext de eMudhra entre abril y julio de 2026.

Dos de estos CVE tienen puntuación CVSS de la organización que los asignó: CVE-2026-115557 es crítica con 9.4 (CVSS 4.0, Python Software Foundation) y CVE-2026-114820 es crítica con 9.1 (CVSS 3.1, Oracle). El registro CVE-2026-111943 de Go no tiene puntuación. Mozilla tampoco puntuó CVE-2026-113470 (Firefox); el enriquecimiento de CISA del registro le asigna 5.4, gravedad media (CVSS 3.1).

El sitio del incidente sigue decenas más, incluidos 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 y mitmproxy 12.3; LibreOffice, Godot, certbot y containerd seguían pendientes a 27 de octubre.

Las herramientas que incluyen su propio Node solo heredan la corrección al pasar a un entorno de ejecución corregido. mongosh anterior a 2.14.0 verifica contra el almacén de confianza del entorno Node del host, mientras que 2.14.0, publicado el 23 de octubre de 2026, incluye Node 24.22.1, que incorpora la lista de claves bloqueadas.

¿Cómo lo corrijo?

Aplique los parches a todos los clientes, navegadores o no, y sustituya cualquier certificado que encadene a emSign ECC Root CA - G3 antes del 27 de octubre. Como operador de clientes, actualice en este orden:

1. Los navegadores y sistemas operativos se actualizan solos; confirme que están al día, ya que los bloqueos llegaron mediante CRLSets de Chrome (17 de octubre), OneCRL de Firefox (17 de octubre), Google Play services de Android (19 de octubre), actualizaciones automáticas de la lista de confianza de Apple (desde el 19 de octubre, según su aviso) y las de Microsoft (20 de octubre).

2. Actualice todos los clientes de la tabla que no son navegadores:

   • Go: recompile los binarios con 1.27.3 o 1.26.10.
   • Node.js: actualice los entornos de ejecución y todas las aplicaciones que incluyan uno.
   • Python: actualice a 3.15.2, 3.14.10, 3.13.18, 3.12.16 o 3.11.18, las primeras versiones cuyo módulo ssl incluye la lista de bloqueos de CVE-2026-115557, o fije certifi en 2026.10.19 o posterior.
   • Java: actualice a las compilaciones extraordinarias de Azul o a otro JDK que bloquee las claves.
   • Electron: recompile las aplicaciones con 42.11.16 o posterior.

   Advertencia: las versiones Python 3.15.1, 3.14.9 y 3.13.17 del 21 de octubre no incluyen la lista de bloqueos. Incorporan pip 26.2.2 con certifi 2026.10.19 integrado, que solo protege las operaciones del propio pip.

3. En las distribuciones, instale el paquete ca-certificates actualizado; en RHEL 7, donde el paquete estaba pendiente, aplique la solución temporal de lista de bloqueos del almacén de confianza documentada por Red Hat.

En macOS en particular, curl, git y Python incluido de línea de comandos verifican contra /etc/ssl/cert.pem sin comprobar revocaciones. El aviso 149555 de Apple afirma que la plataforma bloquea los doce certificados intermedios desde el 19 de octubre y la raíz desde el 23 de octubre, y que la corrección de /etc/ssl/cert.pem, el archivo que comprueban esas herramientas, «estará disponible en una futura actualización de software».

Hasta entonces, retire emSign ECC Root CA - G3 de ese archivo con el script de eliminación publicado en el sitio del incidente. Un segundo paso retira también la raíz AAA Certificate Services de Sectigo para bloquear las seis copias firmadas de forma cruzada; advierte de que retirar AAA puede romper sitios no relacionados y de que una actualización de macOS podría restaurar el archivo.

Como operador de un sitio web con certificado bajo emSign ECC Root CA - G3, no hay solución temporal: el programa Chrome Root de Google indica que los operadores «deben adquirir e instalar inmediatamente un nuevo certificado TLS de otra jerarquía PKI incluida en Chrome Root Store», antes de que la retirada de la raíz llegue a los dispositivos la mañana del 27 de octubre, hora del Pacífico.

Chrome también advirtió de que los clientes ACME estándar no sustituyen certificados fuera de su ventana de renovación salvo que admitan ACME Renewal Information (ARI) o alguien intervenga manualmente; eMudhra estima que deben migrarse unos 30.000 certificados, alrededor del 97 por ciento emitidos mediante ACME. Las universidades comunicaron una vía práctica: los certificados RSA de InCommon bajo la raíz G1 no afectada de eMudhra siguen funcionando hoy, y Let's Encrypt es la alternativa habitual.

¿Cuál es la causa raíz?

La clave privada de una CA intermedia debe ser un número aleatorio impredecible; la ceremonia de claves de eMudhra produjo, junto a las claves robustas previstas, un segundo conjunto tan predecible que los propios certificados públicos las revelan.

Las ocho intermedias, seis para TLS (EM DV, EM OV y EM EV TLS CA en variantes G3B y G3C) y dos para firma de código (EM OV CS CA G3B y G3C), se crearon bajo emSign ECC Root CA - G3 en una ceremonia de generación de claves el 30 de abril de 2025, sobre módulos de seguridad de hardware certificados FIPS 140-2 nivel 3.

En su declaración del incidente, eMudhra dijo que «un paso de encapsulado/desencapsulado de claves produjo un segundo conjunto de claves débiles junto a las claves robustas originales». El encapsulado empaqueta una clave para transferirla y el desencapsulado vuelve a desempaquetarla. eMudhra añadió que «las claves débiles fueron las publicadas en los almacenes raíz de los navegadores».

El sitio del incidente expresa claramente la consecuencia: «La CA generó incorrectamente las claves privadas de los certificados intermedios. Esto significa que cualquiera puede recuperarlas a partir de los certificados». Scott Helme lo verificó en la práctica, recuperando las ocho claves de los certificados públicos en menos de un segundo en su portátil.

Uno de los ocho valores es el número 4; los demás también son enteros inferiores a 256.

Después salieron a la luz dos hechos agravantes.

En 2025, eMudhra había publicado CRL no válidas para seis de las mismas intermedias y afirmó corregirlas «regenerando las CRL con la clave privada adecuada asociada a cada CA intermedia». El 19 de octubre de 2026, la empresa dijo a Mozilla que esas listas se habían «vuelto a firmar con claves defectuosas», las mismas claves débiles. Chrome afirmó que esto «plantea serias preocupaciones sobre la transparencia de eMudhra y su gestión de incidentes».

El 14 de octubre de 2026, eMudhra publicó una CRL para emSign Root TLS CA - G1 cuya firma no se verifica con la clave de esa CA. Un participante en un informe de fallo de Mozilla evaluó que se había firmado con la clave de un certificado OCSP: «un caso de uso de una clave de firma incorrecta, no una prueba de otra clave débil».

A 22 de octubre, eMudhra no había respondido a las doce preguntas de Chrome sobre estos puntos.

¿Cómo se explota?

La explotación es mecánica: recalcular una de las ocho claves privadas a partir del certificado público, falsificar un certificado final para el dominio objetivo e interceptar la conexión de un cliente que omita CT y las comprobaciones de revocación. No se ha observado explotación en ataques reales. La ruta de ataque para un cliente afectado:

1. El atacante calcula una de las ocho claves privadas a partir del certificado intermedio público, el paso que tarda menos de un segundo en un portátil.
2. Emite un certificado para cualquier dominio que quiera suplantar, firmado por esa intermedia, y lo sirve desde una posición que pueda interceptar o responder a las conexiones de la víctima: un punto de acceso malicioso, una interceptación BGP o DNS, un host malicioso en la intranet.
3. El cliente de la víctima construye una cadena desde el certificado final falsificado, pasando por la intermedia, hasta una raíz de confianza: emSign ECC Root CA - G3 en su paquete, o AAA Certificate Services de Sectigo mediante la copia de la intermedia firmada de forma cruzada.
4. Se acepta la conexión si el cliente no exige Certificate Transparency y no ha recibido los bloqueos de revocación ni un paquete actualizado. Exigir CT obligaría al atacante a registrar públicamente el certificado falsificado, donde podría detectarse. Los navegadores no cumplen ninguna de las dos condiciones de vulnerabilidad y están protegidos; la mayoría de las herramientas de línea de comandos, entornos de ejecución incluidos y clientes integrados históricamente fallan en ambas protecciones y estuvieron expuestos hasta actualizarse.

El hecho mitigante decisivo es que nunca se registró en Certificate Transparency ningún certificado que encadenara a las seis intermedias TLS antes de aplicar los bloqueos. Los navegadores que exigen CT requieren un certificado registrado, por lo que ningún certificado falsificado de esas intermedias llegó a Chrome, Edge, Firefox o Safari. Los registros CT no permiten saber si alguien usó las claves contra clientes sin CT, y el sitio del incidente indica que se desconoce.

¿Cómo transcurre el ataque?

El flujo es lineal: calcular la clave a partir del certificado público, falsificar un certificado final para el dominio objetivo, situarse en la ruta de conexión y dejar que un cliente sin CT valide la cadena.

¿Qué puede hacer un atacante?

Contra un cliente sin corregir que no exige CT, el atacante puede suplantar cualquier sitio o servicio al que el cliente se conecte por TLS: recopilar credenciales, servir malware como fuente de actualizaciones o redirigir tráfico API, todo con un certificado en el que el cliente confía plenamente. Las condiciones:

• Una posición de red que permita interceptar o responder al tráfico de la víctima. No se necesita ninguna acción de la víctima más allá de conectarse.
• Un cliente que confíe en una de las raíces o firmas cruzadas afectadas, no exija CT y no haya recibido un bloqueo. Esa combinación excluye los navegadores actuales e incluye herramientas basadas en curl, entornos de ejecución y aplicaciones con paquetes propios, aplicaciones Electron construidas antes de las versiones corregidas y dispositivos IoT.
• Nada más. Las claves nunca fueron robadas porque no hacía falta: en la práctica, se publicaron dentro de los propios certificados.

Las dos intermedias de firma de código amplían la superficie teórica al código firmado en plataformas que confían en ellas, aunque el verificador TLS de Chrome no construirá una ruta mediante una intermedia restringida a firma de código y no se ha comunicado abuso de esa firma. Certificate Transparency, el registro que confirma que ningún certificado TLS falsificado llegó a los navegadores, solo cubre certificados TLS, por lo que no ofrece un rastro comparable para código firmado.

¿Por qué funciona la corrección?

La corrección funciona porque cierra todas las rutas que podría seguir una cadena falsificada: las listas de claves bloqueadas rechazan las propias claves débiles, las retiradas de los paquetes cortan la raíz y la revocación distribuida bloquea las intermedias en los navegadores. Cada mecanismo tiene una cobertura distinta:

• Listas de claves bloqueadas, la protección más fuerte: crypto/x509 de Go, Node.js y el módulo ssl de Python rechazan cualquier certificado que contenga una de las ocho claves, incluidas las copias firmadas de forma cruzada por Sectigo. Python compara el hash SHA-256 del SubjectPublicKeyInfo de cada certificado independientemente de la política SSLContext, y la lista de Go no puede desactivarse.
• Retirada de paquetes, la protección más amplia: certifi, webpki-roots, Debian, Ubuntu, Fedora, RHEL y otros paquetes de distribuciones retiran por completo emSign ECC Root CA - G3, cortando todos los certificados bajo esa raíz, legítimos o falsificados.
• Revocación distribuida, la más rápida: CRLSets, OneCRL y las actualizaciones de la lista de confianza de Microsoft bloquean las intermedias para los navegadores sin actualizar el software.

Los límites importan. Una lista de bloqueos solo ayuda cuando se recompila o actualiza el software; los binarios Go deben recompilarse.

Retirar una raíz de un paquete también corta los certificados legítimos bajo ella, como advirtieron Mozilla, Canonical y Red Hat, y es exactamente lo que hace que los aproximadamente 30.800 certificados activos dejen de funcionar cuando Chrome retira la propia raíz el 27 de octubre.

La protección basada en revocación solo cubre clientes que realmente consumen datos de revocación, algo que generalmente no hacen los clientes afectados que no son navegadores. Esa brecha es precisamente la razón de las listas de bloqueos de Go, Node.js y Python. Como expresó Filippo Valsorda en la incidencia de Go:

«Los almacenes raíz de Linux se mantienen de forma demasiado irregular para que la revocación llegue a las aplicaciones, así que las claves se rechazan en el código».

¿Cómo compruebo si me comprometieron?

No hay un método publicado para detectar usos indebidos pasados de las claves contra clientes sin CT, y el sitio del incidente afirma que se desconoce si alguien explotó la generación defectuosa antes del 17 de octubre. Lo que sí puede verificar:

• En el cliente, pruebe los cuatro hosts de comprobación de la sección «¿Estoy afectado?» en cada entorno relevante, incluidos contenedores y máquinas de compilación. El sitio también publica chains.zip con cada cadena servida en formato PEM para verificación sin conexión con OpenSSL, además de estadísticas de conexiones exitosas de los comprobadores por agente de usuario.
• En el servidor, inventaríe sus certificados para localizar cualquiera que encadene a emSign ECC Root CA - G3 o emSign Root TLS CA - G3 mediante el monitor de registros CT que prefiera; todo lo encontrado debe sustituirse antes del 27 de octubre, no limitarse a vigilarse.
• En la gestión de certificados, compruebe si su configuración ACME admite ACME Renewal Information (RFC 9773); sin ello, los clientes no sustituyen certificados fuera de la ventana de renovación, por lo que un certificado que caduca en noviembre puede dejar de funcionar el 27 de octubre.

Cronología

• 2025-04-30: la ceremonia de generación de claves de eMudhra crea las ocho intermedias y produce el conjunto de claves débiles junto al robusto.
• 2025: eMudhra publica CRL no válidas para seis de las mismas intermedias; después reconoce que se «volvieron a firmar con claves defectuosas».
• 2026-10-17: Wayne comunica las claves recuperables a los programas raíz con pruebas firmadas; Chrome distribuye un bloqueo CRLSet a las 19:45 UTC y Mozilla publica OneCRL a las 22:59 UTC.
• 2026-10-19: se notifica a los almacenes de confianza derivados; Android recibe el bloqueo mediante Google Play services hacia las 22:00 UTC; Apple empieza a bloquear los doce certificados intermedios en sus dispositivos, según su aviso; eMudhra informa a Mozilla de que las CRL de 2025 se volvieron a firmar con las claves defectuosas.
• 2026-10-20: Mozilla y Google publican información; Go lanza 1.27.3 y 1.26.10; certifi publica 2026.10.19; Firefox 158.0.1 y ESR incluyen el bloqueo; llegan los bloqueos de la plataforma Microsoft; Mozilla retira la raíz de NSS.
• 2026-10-21: eMudhra divulga el fallo de la ceremonia en un comunicado para BSE; CERT-In publica CIAD-2026-0050; Red Hat publica RHSB-2026-012; Node.js publica su lista de bloqueos; Azul lanza sus compilaciones extraordinarias Zulu y Zing que bloquean las ocho intermedias; las acciones de eMudhra caen un 20 por ciento en Bombay.
• 2026-10-22: el consejo de eMudhra decide abandonar el negocio global SSL/TLS (alrededor del 1 por ciento de sus ingresos); las doce preguntas de Chrome a eMudhra siguen sin respuesta pública.
• 2026-10-23: Apple también empieza a bloquear emSign ECC Root CA - G3, según su aviso.
• 2026-10-24: Python anuncia la lista de bloqueos del módulo ssl como CVE-2026-115557 y adapta la corrección a las ramas de mantenimiento 3.11 a 3.15.
• 2026-10-25: Python publica 3.15.2, 3.14.10, 3.13.18, 3.12.16 y 3.11.18, las primeras versiones con la lista de bloqueos; certifi 2026.10.23 pasa a ser la versión actual.
• 2026-10-27: Chrome Root Store versión 43 retira emSign ECC Root CA - G3, con llegada prevista a los dispositivos la mañana del 27 de octubre, hora del Pacífico. La actualización de macOS de Apple que cubre las herramientas de línea de comandos aún no se había publicado la mañana del 27 de octubre, y su índice de publicaciones de seguridad no contenía ninguna entrada para este incidente, por lo que los pasos manuales siguientes sobre /etc/ssl/cert.pem siguen siendo la corrección para curl, git y Python incluidos.

Preguntas frecuentes

¿Es seguro usar mi navegador ahora mismo?

Sí. Chrome, Edge, Firefox y Safari exigen Certificate Transparency, y nunca se registró en CT ningún certificado de las seis intermedias TLS, por lo que ningún certificado falsificado de esas intermedias llegó a un navegador, incluso antes de los bloqueos de revocación. Los bloqueos desde el 17 de octubre cierran la puerta a cualquier cosa que un navegador pudiera aceptar sin comprobar CT.

Actualicé macOS. ¿Por qué curl sigue siendo vulnerable?

Apple bloqueó los doce certificados intermedios (cada intermedia TLS bajo la raíz eMudhra y con firma cruzada de Sectigo) el 19 de octubre, y la raíz el 23 de octubre, mediante actualizaciones automáticas de configuración de certificados. Estas protegen Safari, Mail y las aplicaciones que usan los frameworks de red y seguridad de Apple.

curl, git y Python incluidos verifican contra /etc/ssl/cert.pem sin comprobar revocaciones. El aviso 149555 de Apple dice que esa corrección «estará disponible en una futura actualización de software». Hasta entonces, retire la raíz del archivo manualmente o con el script del sitio del incidente; una actualización de macOS podría restaurarlo.

¿Mi sitio web dejará realmente de funcionar el 27 de octubre?

Solo si su certificado encadena a emSign ECC Root CA - G3, como ocurría con unos 30.800 certificados sin caducar a 21 de octubre. Para esos, sí: cuando Root Store versión 43 llega a un usuario de Chrome, la cadena deja de validar. Google recomienda a los operadores sustituir el certificado inmediatamente, sin esperar a la retirada, y recordar que los clientes ACME no renuevan antes de tiempo sin soporte ARI.

¿Hackearon eMudhra?

No se vulneró ningún sistema ni se robaron claves, lo que hace inusual el incidente. Las claves se generaron mal, y una clave mal generada es pública en la práctica: cualquiera con el certificado podía calcularla, sin intrusión. eMudhra afirma que siete de las ocho intermedias nunca se usaron en producción y que ninguna de las ocho, incluida la que sí se utilizó, emitió un certificado de entidad final.

¿Debo retirar también la raíz Sectigo?

Solo en clientes que no pueda corregir de otro modo. Seis de las ocho intermedias también existen con firma cruzada bajo la raíz AAA Certificate Services de Sectigo, por lo que retirar solo emSign ECC Root CA - G3 deja abiertas esas rutas. Pero retirar AAA también corta todos los certificados legítimos bajo ella; por eso las actualizaciones de distribuciones que retiran ambas advierten de interrupciones, y por eso las correcciones mediante listas de claves bloqueadas son preferibles cuando existen.

¿Es lo mismo que la actualización de emergencia de Go que instalé el 20 de octubre?

Sí. Go publicó 1.27.3 y 1.26.10 ese día sin nombrar a la CA, bloqueando ocho hashes de claves en crypto/x509 por su vía URGENT; esos ocho hashes corresponden a estos ocho certificados. El equipo de seguridad de Go dijo que mantuvo vagas las notas de publicación porque el fallo era trivial de explotar y esperaba que los detalles se hicieran públicos ese día.

Encuentre los certificados que dejarán de funcionar el 27 de octubre

Utilice Ostorlab Attack Surface Discovery para inventariar sus dominios y hosts expuestos a Internet. Después compruebe si la cadena de certificados que sirve cada uno incluye emSign ECC Root CA - G3 y sustituya cualquier coincidencia antes de que Chrome retire la raíz el 27 de octubre.

Referencias

• Sitio del incidente con las pruebas, hosts de comprobación, paquete de cadenas para uso sin conexión y tabla de proveedores que han publicado parches, mantenido desde el 20 de octubre de 2026: https://emudhra.we-have-a-problem.com/ (consultado el 27 de octubre de 2026)
• Aviso 149555 de Apple sobre las CA intermedias eMudhra comprometidas: bloqueo desde el 19 de octubre, de la raíz desde el 23 de octubre, corrección de /etc/ssl/cert.pem en una actualización futura y pasos de retirada manual; índice de publicaciones de seguridad de Apple, consultado la mañana del 27 de octubre de 2026 para buscar una entrada del incidente: https://support.apple.com/en-us/149555 y https://support.apple.com/en-us/100100 (consultados el 27 de octubre de 2026)
• Declaración de Azul sobre el compromiso de CA intermedias eMudhra, 22 de octubre de 2026, con las compilaciones extraordinarias Zulu y Zing del 21 de octubre que bloquean las ocho intermedias: https://www.azul.com/newsroom/azul-statement-on-the-emudhra-intermediate-ca-certificates-compromise/ (consultada el 26 de octubre de 2026)
• Google sobre la protección de usuarios de Chrome y Android frente a los certificados de CA intermedias eMudhra comprometidos, 20 de octubre de 2026: https://blog.google/security/protecting-chrome-and-android-users-from-compromised-emudhra-intermediate-ca-certificates/ (consultado el 25 de octubre de 2026)
• Mozilla sobre la protección de usuarios de Firefox, 20 de octubre de 2026: https://blog.mozilla.org/security/2026/10/20/protecting-firefox-users-following-the-compromise-of-emudhra-intermediate-certificates/ (consultado el 25 de octubre de 2026)
• Hilos de las listas de políticas de Chrome Root Program y Mozilla citados en la cobertura: https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/0R3XLJL6FuE/m/Kp1v6CPuAAAJ (consultados el 25 de octubre de 2026)
• Comunicado de eMudhra presentado ante la bolsa BSE sobre el fallo de la ceremonia del 30 de abril de 2025: https://www.bseindia.com/xml-data/corpfiling/AttachLive/6be0c423-b335-494b-86f3-54c561c3a5f9.pdf (consultado el 25 de octubre de 2026)
• Declaración de eMudhra sobre el incidente de seguridad de certificados: https://emudhra.com/en/post/certificate-security-incident (consultada el 25 de octubre de 2026)
• Recuperación independiente de claves por Scott Helme: las ocho en menos de un segundo, una de ellas el número 4: https://scotthelme.co.uk/eight-bits-of-trust-emudhras-ca-keys-cracked-in-milliseconds/ (consultada el 25 de octubre de 2026)
• The Hacker News sobre las ocho claves de CA comprometidas y las correcciones de emergencia del ecosistema, 20 de octubre de 2026, actualizado el 21 de octubre: https://thehackernews.com/2026/10/eight-emudhra-ca-keys-compromised.html (consultado el 25 de octubre de 2026)
• The Hacker News sobre la salida de eMudhra del negocio global SSL/TLS, los aproximadamente 30.800 certificados sin caducar, la concentración en InCommon y la retirada de Chrome del 27 de octubre, 22 de octubre de 2026: https://thehackernews.com/2026/10/emudhra-to-exit-global-ssltls-business.html (consultado el 25 de octubre de 2026)
• Versiones de emergencia de Go que bloquean las ocho claves, CVE-2026-111943: https://groups.google.com/g/golang-announce/c/66pojueaQek y https://cveawg.mitre.org/api/cve/CVE-2026-111943 (consultadas el 25 de octubre de 2026)
• Anuncio de la lista de bloqueos del módulo ssl de Python, CVE-2026-115557, 24 de octubre de 2026: https://www.openwall.com/lists/oss-security/2026/10/24/5 y https://cveawg.mitre.org/api/cve/CVE-2026-115557 (consultado el 25 de octubre de 2026)
• Registro CVE-2026-113470 de Firefox, sin puntuación de Mozilla y con enriquecimiento de CISA de 5.4, gravedad media: https://cveawg.mitre.org/api/cve/CVE-2026-113470 (consultado el 27 de octubre de 2026)
• Registros de cambios de CPython que confirman la primera inclusión de la lista de bloqueos en 3.15.2, 3.14.10, 3.13.18 y 3.12.16 el 25 de octubre, y vista comparativa de CPython que confirma que v3.11.18, etiquetada el mismo día, contiene la adaptación: https://docs.python.org/3.15/whatsnew/changelog.html y https://github.com/python/cpython/compare/af52b41afa4330fb38583db553631baa2f122f90...v3.11.18 (consultados el 26 de octubre de 2026)
• Alerta extraordinaria de Oracle Java que retira las raíces eMudhra, CVE-2026-114820: https://www.oracle.com/security-alerts/alert-cve-2026-114820.html (consultada el 25 de octubre de 2026)
• Aviso certifi GHSA-6q48-6c7w-9gw2 que retira la raíz emSign: https://github.com/certifi/python-certifi/security/advisories/GHSA-6q48-6c7w-9gw2 (consultado el 25 de octubre de 2026)
• Aviso uv GHSA-hq85-5cpj-mr62 que retira la raíz emSign: https://github.com/astral-sh/uv/security/advisories/GHSA-hq85-5cpj-mr62 (consultado el 25 de octubre de 2026)
• Boletín de seguridad Red Hat RHSB-2026-012 con la solución temporal del almacén de confianza RHEL: https://access.redhat.com/security/vulnerabilities/RHSB-2026-012 (consultado el 25 de octubre de 2026)
• Aviso CERT-In CIAD-2026-0050, 21 de octubre de 2026: https://www.cert-in.org.in/s2cMainServlet?pageid=PUBVLNOTES02&VLCODE=CIAD-2026-0050 (consultado el 25 de octubre de 2026)
• WARP, clientes 1.1.1.1 y cloudflared 2026.10.2 corregidos de Cloudflare: https://blog.cloudflare.com/emudhra-certificate-compromise (consultado el 25 de octubre de 2026)
• Publicación de mongosh 2.14.0, 23 de octubre de 2026, que incluye Node 24.22.1 con la lista de claves bloqueadas, mientras las versiones anteriores verifican contra el almacén de confianza del entorno Node del host: https://github.com/mongodb-js/mongosh/releases/tag/v2.14.0 (consultada el 27 de octubre de 2026)