En la noche del 17 de octubre de 2026, un investigador de seguridad que opera con el alias "Wayne" envió un mensaje desconcertante a los equipos de confianza digital de Mozilla, Google, Apple y Microsoft: firmas digitales criptográficas, cada una de ellas usando la clave privada de una de las ocho autoridades certificadoras intermedias de la empresa india eMudhra. El mensaje era simple — "We have a problem here - Wayne" — pero el significado era devastador. Quien pudiera verificar esas firmas contra la clave pública correspondiente sabía, sin sombra de duda, que Wayne poseía acceso a las claves privadas que deberían estar guardadas en módulos de seguridad de hardware (HSM) bloqueados y protegidos por múltiples autorizaciones.
Las consecuencias potenciales de este compromiso son de las más graves para la infraestructura digital global. Los certificados intermedios TLS actúan como eslabones en la cadena de confianza que conecta la raíz de una autoridad certificadora (CA) a los certificados finales que los sitios web usan para autenticarse. Cuando una clave intermedia es comprometida, cualquier persona que la posea puede crear certificados HTTPS válidos para cualquier dominio — google.com, banco.gov.br, tu-proveedor-de-correo.com — que los navegadores aceptarían como legítimos. Esto habilita ataques de "man-in-the-middle" en los que un atacante intercepta el tráfico cifrado de usuarios, leyendo y modificando comunicaciones que deberían ser privadas, desde contraseñas bancarias hasta mensajes de salud.
Lo que fue comprometido
Las ocho claves comprometidas pertenecen a certificados intermedios emitidos por eMudhra, una empresa india de confianza digital que opera bajo la marca emSign, con operaciones en Estados Unidos, Países Bajos e India. Seis de estos certificados están destinados a la emisión de certificados TLS para sitios web — abarcando validación de dominio (DV), validación de organización (OV) y validación extendida (EV). Las dos restantes son certificados de firma de código.
Cada familia de certificados TLS (DV, OV, EV) tiene variantes G3B y G3C, emitidas bajo la raíz "emSign Root TLS CA - G3". Estas claves intermedias están diseñadas para mantener la clave raíz offline en HSMs auditados, permitiendo que la CA opere con más flexibilidad sin exponer la raíz principal. Lo que hace este incidente particularmente preocupante no es solo el número de claves comprometidas — ocho simultáneamente sería improbable en un fallo aislado — sino el hecho de que las ocho pertenecen a la misma autoridad, lo que sugiere un fallo sistémico en lugar de un accidente puntual.
La respuesta de las grandes empresas
La velocidad de respuesta fue impresionante. El Chrome Root Program recibió el reporte a las 18:05 UTC del 17 de octubre y, en menos de dos horas, a las 19:45 UTC, ya tenía una actualización de CRLSet bloqueando los seis intermedios TLS. Mozilla recibió la misma notificación a las 20:06 UTC y, a las 22h59 UTC, había distribuido un bloqueo vía OneCRL para todos los usuarios Firefox con configuraciones estándar — todo sin que fuera necesario actualizar o reiniciar el navegador.
Apple bloqueó los certificados el 19 de octubre, Microsoft el 20 de octubre, y el equipo del proyecto Go (el lenguaje de programación de Google) lanzó actualizaciones de emergencia en las versiones 1.27.3 y 1.26.10, asignadas al CVE-2026-111943. El proyecto Go fue particularmente agresivo: en lugar de confiar en listas de revocación externas, el código fuente fue alterado para rechazar hardcoded cualquier cadena de confianza que contuviera una de las oito claves comprometidas. El Python certifi y el Rust webpki-roots también fueron actualizados, demostrando que el impacto va mucho más allá de los navegadores.
Por qué los intermedios son peores que los certificados "hoja"
Para entender la gravedad, es útil diferenciar dos tipos de certificados. Un certificado "hoja" (end-entity) es el que un sitio web individual — digamos, un sitio de noticias — usa para cifrar su conexión. Si la clave de ese certificado se compromete, el dueño del sitio genera un nuevo par de claves, solicita un reemplazo y el problema se resuelve. El impacto es contenido.
Un certificado intermedio es diferente. Existe para delegar autoridade de firma sin exponer la raíz. Un atacante con una clave intermedia hereda toda la confiança que los usuarios colocan en esa línea jerárquica. Puede emitir certificados válidos para cualquier dominio, omitir las verificaciones de validación que las CAs legítimas normalmente aplican y crear una fachada digital indistinguible para servicios bancarios, gubernamentales o corporativos.
El problema del cross-signing
La situación se complicó por una práctica chamada "cross-signing". Para garantir que dispositivos mais antigos — que tal vez não tivessem a versão mais recente das raízes de eMudhra — continuassem funcionando, los intermediários comprometidos foram cross-signados por una autoridade establecida: la AAA Certificate Services de Sectigo. Isto significa que um cliente poderia construir una cadena de confiança válida que passa pela raiz da Sectigo em vez da eMudhra.
Se um navegador simplemente desconfiasse a raiz da eMudhra, um atacante ainda poderia presentar uma cadeia que passa pela Sectigo. La solución llegó cuando los navegadores comenzaron a bloquear los hashes SPKI (Subject Public Key Info) de las claves intermedias comprometidas — es decir, bloquearon las propias claves públicas, não apenas los números de série dos certificados. Isto cierra todos los caminos de construção de cadena, independientemente de qué raíz válida use el cliente. La propia Sectigo retiró los cross-signs de los intermediários afetados.
Lo que aún no sabemos
Hasta el momento de la publicación, ninguna de las partes involucradas reveló cómo las claves privadas salieron del control de eMudhra, cuándo ocurrió o si alguien además del investigador Wayne aún las posee. Las possibilidades vão desde um insider malintencionado até un fallo en un HSM, un backup filtrado ou una violação de la infraestrutura de firma. eMudhra no publicó ningún aviso en su repositorio de servicios de confianza até el 20 de octubre.
El investigador q3k demostró que es posible verificar la posesión de la clave públicamente: basta tomar la firma de "We have a problem here - Wayne" y verificarla con OpenSSL usando la clave pública del certificado intermedio. Una verificación exitosa prueba que el firmante poseía la clave privada en el momento de la firma. Isto estabelece el compromiso sin, irónicamente, exponer la própria chave.
El impacto real y el futuro
Ninguno de los informes, incluyendo el aviso de seguridad de Mozilla (MFSA2026-113), confirmó explotación en producción. Esto se debe, en parte, a que un certificado TLS válido es solo la mitad de la batalla para un atacante — él también necesita controlar el DNS del dominio visado ou la ruta IP de la víctima. Además, Chrome no encontró ningún certificado TLS firmado por estos intermediários registrado en los logs de Certificate Transparency antes de aplicar el bloqueo, lo que significa que ningún certificado fraudulento habría sido confiable por defecto en Chrome.
Por otro lado, el incidente plantea una pregunta desconfortable: si el compromiso não foi explotado en producción, cuánto tiempo llevó? eMudhra es una de las muchas CAs que operan bajo el riguroso régimen del CA/Browser Forum, que exige separación de deberes, autorizaciones multi-persona y HSMs altamente auditados. Oito claves comprometidas simultaneamente apuntan a una falla estructural — y si esto ocurrió aquí, cuántas otras CAs están igualmente vulnerables?
La verdad incómoda es que la infraestructura de claves públicas, que subyace a cada conexión segura en internet, permanece frágil. Quando la seguridad de una CA falla, la carga de la protección se traslada de la CA a cientos de millones de usuarios finales — y essa proteção só funciona si los proveedores de software pueden empujar cambios de confiança más rápido de lo que los atacantes los explotan. Si esta carrera aún se está ganando es uma pregunta abierta.
Fuentes: heise online, The Hacker News, Mozilla Security Blog
✓ Fuentes independientes cruzadas y verificadas antes de la publicación
