La clave secreta era el número 4: Cloudflare detecta 22.000 intentos de conexión con las claves débiles de eMudhra, aún aceptadas en grandes redes

• Adrián Villellas @AdrianVillellas
• Ingeniero informático, divulgador y creador de contenido tecnológico desde 2017, escribiendo para blogs y medios tanto en español como en inglés.
• • 10/11/2026 22:03
  • Actualizado: 10/11/2026 22:03

Cloudflare ha medido el alcance de las claves débiles de eMudhra, una autoridad de certificación india cuya clave privada más simple equivalía al número 4. La empresa registró unos 22.000 intentos de conexión con ellas en una semana. En las grandes redes, más de la mitad de sus sondeos aún acepta la cadena comprometida.

Maxime Guerreiro, Miguel de Moura y Bas Westerbaan firman el análisis, publicado el 30 de octubre de 2026. Una autoridad de certificación garantiza a los navegadores que una web es quien dice ser. Quien controle una de sus claves puede fabricar certificados falsos para dominios ajenos.

Claves de un solo número

Según enumera Cloudflare, los valores eran 4, 56, 66, 115, 155, 156, 230 y 237. Una clave privada segura es un número enorme y aleatorio. Estas tenían tres cifras como máximo.

En casos anteriores como DigiNotar o TÜRKTRUST, el acceso a las claves estaba mucho más limitado. Aquí, escriben los autores, las claves «podían recuperarse casi al instante por cualquiera» desde los propios certificados públicos.

Pertenecían a certificados intermedios, los eslabones entre el certificado de una web y la raíz de confianza. Con ellas se podían emitir certificados para cualquier dominio.

Dieciocho meses sin detectarse

eMudhra sitúa el origen en una ceremonia de generación de claves del 30 de abril de 2025. Su comunicado explica que un paso técnico creó un segundo juego de claves débiles. Ese juego acabó publicado en los almacenes de confianza.

El error sobrevivió unos 18 meses y dos ciclos de auditoría. La compañía aún no da por confirmada la causa exacta. «El fallo fue nuestro», admitió su equipo directivo el 26 de octubre.

Desde el 30 de octubre, KPMG actúa como revisora externa. eMudhra ha dejado de vender certificados TLS de confianza pública. Calcula en unos 30.800 los emitidos bajo las jerarquías afectadas, todos de clientes de Estados Unidos.

Chrome reaccionó en 100 minutos

Un investigador dio la alarma el 17 de octubre. Chrome recibió el informe a las 18:05 UTC y publicó el bloqueo a las 19:45 UTC. Así lo detalló Dennis Jackson en el foro de políticas de seguridad de Mozilla.

Mozilla recibió su aviso a las 20:06 UTC y completó el bloqueo a las 22:59 UTC. Usó OneCRL, una lista de revocación que, según el equipo de seguridad de Firefox, no exige actualizar ni reiniciar el navegador.

Cloudflare supo del problema el 19 de octubre, hacia las 17:00 UTC. Terminó sus mitigaciones de servidor al día siguiente. Sus proxies Pingora, por donde sale la mayoría de sus conexiones, quedaron corregidos en horas.

El caso se suma a otros de claves de cifrado mal protegidas. También llega en plena carrera por renovar la criptografía antes de 2035.

Dos tercios eran sitios de prueba

El registro en Pingora quedó activo el 21 de octubre. En la semana siguiente, Cloudflare contó unos 22.000 intentos de conexión. Dos tercios eran descargas de webs de prueba creadas para comprobar el fallo.

Casi todo el resto venía de servidores con un certificado propio firmado por esas intermedias. Unas 160 conexiones destacaron porque nombraban dominios de otras organizaciones, algunos de dispositivos domésticos. Varios certificados superaban los dos años de validez, más de lo que permite cualquier autoridad pública.

Cloudflare cree que era la configuración por defecto de esos servidores, sin intención de interceptar su tráfico. Todas las conexiones que verificaban el certificado acabaron rechazadas.

WebView y bots siguen expuestos

La empresa añadió dos peticiones invisibles a parte de sus páginas de desafío, las comprobaciones antibots previas a abrir una web. Una iba a un servidor con certificado de eMudhra. La otra, de control, usaba uno normal.

Tras 50 millones de sondeos, el balance es desigual. «Los navegadores modernos actualizados están en su mayoría parcheados, pero los bots y los navegadores antiguos no», escriben los autores.

Android WebView, que muestra páginas dentro de las aplicaciones, sigue aceptándolas entre un 30 % y un 40 % según el texto de Cloudflare. Su gráfico es menos uniforme: la línea de WebView ronda el 20-30 % sin señales de bot y el 45-50 % con ellas. En las grandes redes, más de la mitad de los sondeos la aceptó, con señales de bot y sin ellas.

Google, que acaba de corregir otros 21 fallos en Chrome 156, va más allá. Su aviso del 4 de noviembre retira la confianza por defecto a los certificados de la raíz emSign Root CA G1 con sellos posteriores al 16 de noviembre. Considera insatisfactorias las respuestas de eMudhra sobre cómo maneja sus claves.

Bots sin confirmar, muestra sesgada

Los autores advierten de que el tráfico medido está muy sesgado y contiene bots no confirmados. Solo generan sondeos los clientes que ejecutan JavaScript. Además, la configuración cambió varias veces entre el 23 y el 27 de octubre.

Cloudflare no descarta una interceptación selectiva contra objetivos concretos, aunque asegura que «no hemos visto ninguna de esas señales». eMudhra dice no tener constancia de que alguien explotara las claves antes de hacerse públicas. Su análisis completo de causas sigue pendiente.

Los datos se han publicado en el blog de Cloudflare y en el comunicado de eMudhra.

Crédito de la imagen: Cloudflare.