eMudhra: 8 certificados SSL comprometidos, qué hacer

¿Qué pasó con los certificados de eMudhra?

El 19 de octubre de 2026, alrededor de las 17:00 UTC, Cloudflare detectó que las claves privadas de ocho certificados intermedios de eMudhra estaban comprometidas. No eran certificados menores: los aceptaban navegadores, sistemas operativos y la propia infraestructura de Cloudflare. Con esas claves en mano, un atacante puede emitir un certificado válido para cualquier dominio y usarlo para interceptar o modificar tráfico.

La reacción fue rápida. Un investigador reportó el problema a los root programs en la noche del 17 de octubre. El Chrome Root Program recibió el aviso a las 18:05 UTC y tenía activo un bloqueo vía CRLSet a las 19:45 UTC. Mozilla lo recibió a las 20:06 UTC y completó la distribución de OneCRL a las 22:59 UTC, menos de tres horas después, según The Hacker News. El investigador, identificado por Mozilla solo como Wayne, firmó el mensaje «We have a problem here – Wayne» con cada una de las ocho claves para probar que las controlaba.

eMudhra es una autoridad de certificación india que vende certificados bajo la marca emSign en India, Estados Unidos y Países Bajos, y tenía raíces en los stores de Mozilla, Chrome y Apple. Sus representantes no estaban disponibles de inmediato para responder preguntas, según reportó Ars Technica y recogió DiarioBitcoin.

¿Por qué una clave débil rompe toda la cadena de confianza?

Un certificado intermedio es el que firma los certificados que presentan los sitios web. Quien tenga esa clave privada puede emitir un certificado que el navegador aceptará como legítimo para un dominio que no controla. Es un eslabón silencioso: el usuario ve el candado y no sospecha nada.

Lo llamativo del caso es la magnitud de la debilidad. Según DiarioBitcoin, que cita a Ars Technica, las claves afectadas tenían entre 3 y 8 bits de entropía —los valores identificados fueron 4, 56, 66, 115, 155, 156, 230 y 237— frente a los 384 bits de una clave NIST P-384 normal. Filippo Valsorda, mantenedor de la criptografía del lenguaje Go, lo describió como algo que no debería ser posible y planteó como hipótesis una interfaz de generación de claves con un parámetro de tamaño mal configurado, aunque la información disponible no establece cómo ocurrió.

Hay un dato que juega a favor: hasta el reporte, los registros de Certificate Transparency no mostraban certificados fraudulentos encadenados a los seis intermedios TLS, según el Chrome Root Program. Eso reduce el riesgo histórico, pero no lo elimina. Explotar las claves requiere un ataque activo de intermediario (MITM), y ese tipo de operación está al alcance de quien controla la red local por la que pasa la conexión: una cafetería, una universidad, la red de una oficina.

¿Qué parches están disponibles y cuáles siguen pendientes?

La parte incómoda de este incidente no es el bloqueo en los navegadores —que se resolvió con una actualización remota— sino todo lo demás que valida certificados TLS sin consultar listas de revocación. Estos son los fixes publicados hasta ahora, según The Hacker News:

• Go: versiones 1.27.3 y 1.26.10 rechazan cualquier cadena que contenga una de las ocho claves (CVE-2026-111943). Requiere recompilar el binario; Go 1.25 y anteriores no reciben el fix.
• Firefox: 158.0.1, ESR 115.43.1 y ESR 153.5.1 (CVE-2026-113470).
• NSS: 3.131.1 elimina la raíz emSign ECC Root CA – G3 de la lista de confianza.
• Python certifi: 2026.10.19.
• Rust webpki-roots: 1.0.10.
• Homebrew ca-certificates: 2026-09-25_1.
• Node.js y Composer ca-bundle: sin parche publicado al cierre de esta nota.

Del lado de Cloudflare, la compañía publicó actualizaciones para Cloudflare One Client y la app 1.1.1.1 (v2.5.6 en Android, v1.12.16 en iOS y 2026.8.2115.0 en Windows, macOS y Linux), y para Cloudflare Tunnel (cloudflared) en su versión 2026.10.2. Las mitigaciones del lado servidor para CDN y Zero Trust quedaron desplegadas el 20 de octubre a las 19:20 UTC, según el propio blog de la compañía.

¿Qué significa esto para tu startup?

Si tu producto corre sobre infraestructura cloud, este incidente te toca aunque nunca hayas oído hablar de eMudhra. La lección central es que actualizar el SDK no alcanza: un cliente de API puede delegar la verificación del certificado a una librería HTTP, a un runtime, al sistema operativo o a una configuración propia. Tocar solo la capa de arriba puede no cambiar nada.

Tres acciones concretas para hoy:

• Revisa tu árbol de dependencias, no solo tus dependencias directas. Los paquetes afectados suelen entrar como dependencias indirectas. Si usas Go, Python, Rust o imágenes de contenedor con bundles propios de certificados, verifica versión por versión y reconstruye las imágenes afectadas.
• No desactives la verificación de certificados para silenciar errores. Después de parchear es probable que aparezcan errores de certificado en tus dashboards. Resolverlos apagando la validación elimina exactamente la protección que el parche busca restaurar.
• Revisa tus origin servers si usas modo Full (strict). Cloudflare advirtió que actualizará Automatic SSL/TLS para notificar automáticamente a quienes sigan usando certificados destituidos, algo que puede causar cortes si no se atiende a tiempo.

¿Cómo saber si tu stack está realmente protegido?

La recomendación de Mozilla para quien opera un trust store es escalonada: no hace falta nada donde los clientes verifican revocación de forma confiable y rechazan la conexión cuando no pueden hacerlo; conviene bloquear los ocho intermedios donde el software lo permita; y en el resto de los casos, evaluar quitar la confianza en las raíces que los firmaron.

Ojo con una trampa frecuente: una prueba en el navegador no demuestra que un servicio en segundo plano esté protegido. Tampoco sirve un curl si la aplicación usa un verificador distinto. Hay que validar por la ruta TLS real de cada aplicación.

Un dato tranquilizador para equipos que dependen de mensajería: Signal, WhatsApp y WireGuard no resultan afectadas en los términos descritos, porque no dependen de TLS para proteger la confidencialidad de sus comunicaciones, según DiarioBitcoin.

Conclusión

El incidente de eMudhra deja dos preguntas abiertas que ninguna fuente respondió todavía: cómo salieron las claves de la CA y cuándo. Mozilla dijo que trabaja con la autoridad, otros root programs y los trust stores downstream en la causa raíz. Mientras tanto, Chrome anunció que eliminará la raíz emSign ECC Root CA – G3 en la versión 43 de su root store y está revisando el estado de la otra raíz de eMudhra, emSign Root CA – G1.

La escala del trabajo de remediación es la advertencia real. Valsorda comparó la tarea con una limpieza mayor que la de Heartbleed, la vulnerabilidad de OpenSSL de 2014 que exigió reemitir millones de claves y tardó años en cerrarse del todo. La razón es la misma que hace difícil este tipo de incidentes: no hay un solo interruptor, sino cientos de sistemas, cada uno con su propio ciclo de actualización.

Para un founder, la conclusión práctica es incómoda pero simple. La seguridad de tu producto no depende solo de tu código: depende de la cadena de confianza que heredas de terceros, y esa cadena se puede romper en un eslabón que nunca elegiste. Tener inventario de dependencias, un proceso de reconstrucción de imágenes y la disciplina de no apagar la verificación cuando algo falla vale más que cualquier parche puntual.

Fuentes

• Cloudflare: eMudhra certificate compromise (fuente original)
• The Hacker News: Eight eMudhra CA Keys Compromised
• Mozilla Security Blog: Protecting Firefox users following the compromise of eMudhra intermediate certificates
• DiarioBitcoin: Ocho certificados TLS comprometidos ponen a Internet en alerta

Artículos relacionados:

eMudhra: 8 certificados TLS comprometidos, alerta global Cloudflare OS: la plataforma open source que democratiza agentes de IA en empresas Entre empresas europeas con CDN, 9 de cada 10 usan Cloudflare Let’s Encrypt detiene emisión: qué hacer con tu SSL hoy Cloudflare se vuelve certificate authority con MTCs post-quantum