Ing. Calogero Bono
Cloudflare ha publicado un análisis de seguimiento sobre las ocho claves criptográficas débiles de la autoridad de certificación india eMudhra, descubiertas el 19 de octubre de 2026. Según la empresa, los sistemas más críticos ya están protegidos y no se han detectado interceptaciones de sus conexiones. Sin embargo, los certificados falsos aparecieron en pocas horas, y muchos navegadores, bots y aplicaciones integradas siguen aceptando la cadena comprometida. Para quien gestiona sitios y servicios en línea, el riesgo no es teórico.
Algunos términos antes de entrar en los hechos. CA (certificate authority) es la entidad que emite los certificados en los que se basa el candado HTTPS. Clave intermedia es la clave con la que la CA firma los certificados de los sitios. CRL es la lista de certificados revocados. Certificate Transparency es el registro público de los certificados emitidos, y los SCT son sus recibos. SAN y SNI indican los nombres de dominio presentes en el certificado y el que solicita el cliente.
¿Qué ha pasado con las claves de eMudhra?
Según Cloudflare, eMudhra debía elegir un número de 115 cifras para proteger sus claves y usó el número 4. Las otras siete claves eran igual de débiles, con valores como 56, 66, 115, 155, 156, 230 y 237.
Cloudflare explica que las claves intermedias se pueden reconstruir casi de inmediato por cualquiera, a partir de los certificados públicos. Así, cualquiera puede crear certificados para cualquier dominio, que un cliente no actualizado y sin control de Certificate Transparency aceptaría.
Para la empresa, el caso no tiene precedentes. Incidentes como DigiNotar, TÜRKTRUST y TrustWave habían dado el poder de emitir certificados falsos solo a unos pocos actores.
¿Cómo ha reaccionado Cloudflare?
El 19 de octubre comenzaron los parches en los sistemas de alto impacto, empezando por los proxies Pingora dirigidos a los servidores de los clientes, que gestionan la mayor parte de las conexiones salientes. En pocas horas empezaron a rechazar las claves vulnerables.
Paralelamente, un análisis del código asistido por IA identificó en cuatro horas los demás sistemas que confiaban en esas claves. Para cada uno se abrió un ticket. Las intervenciones urgentes debían hacerse de inmediato, las demás antes del final de la semana pasada. En el momento de la publicación quedan por cerrar pocos tickets de bajo impacto.
¿Se han usado ya las claves para falsificar certificados?
Sí, según Cloudflare. Desde el 21 de octubre, un registro en Pingora anota los certificados firmados con las claves débiles. En una semana contó unos 22.000 intentos de handshake. Dos tercios iban dirigidos a sitios de prueba, y casi todo el resto a servidores que parecen haberse creado por sí mismos un certificado con el intermedio débil. Cada handshake con verificación activa fue rechazado.
Unos 160 casos eran anómalos, con nombres de dominio de otras organizaciones, algunos vinculados a dispositivos IoT para consumidores. Algunos certificados tenían una validez superior a dos años, más de lo que una CA pública puede emitir. Uno data del 20 de octubre a las 18:19 UTC, menos de una hora después de la publicación del aviso de Mozilla.
Para Cloudflare, sin embargo, parecen certificados predeterminados de servidores y no intentos de interceptación. El caso es similar a otros en los que una vulnerabilidad se sondea de inmediato, como el de Oracle E-Business Suite.
¿Cuántos visitantes siguen vulnerables?
Cloudflare no puede probar directamente a los visitantes sin interrumpir las conexiones. Por ello añadió dos sondas a las páginas de verificación, una con certificado de eMudhra y otra de control. En una semana recogió 50 millones de sondeos.
El panorama que describe es este.
- Los navegadores modernos y actualizados están en su mayoría protegidos.
- Los bots y los navegadores antiguos no.
- Las aplicaciones con navegador integrado, como Android WebView, siguen aceptando la cadena en el 30-40 % de los casos.
- En las grandes redes, más de la mitad de las sondas acepta la cadena comprometida.
Tras algún avance el primer fin de semana, la tendencia es plana. Sin embargo, el tráfico está sesgado por bots no confirmados, y solo los clientes que ejecutan JavaScript envían sondas.
Límites que conviene conocer
eMudhra declara un error en un script de generación de claves, pero aún no lo ha compartido. Quedan por aclarar el papel de los revisores y de los cross-signers, y por qué una CRL se firmó primero con una clave quizás correcta y luego con la débil. Cloudflare descarta interceptaciones solo a partir de señales indirectas. Una interceptación dirigida no queda descartada. Además, los datos de los visitantes están sesgados por los bots.
Qué cambia para quien trabaja con lo digital
Si gestionas sitios, aplicaciones o software de gestión, comprueba que servidores, bibliotecas y clientes rechacen las claves de eMudhra. También importan los programas que se conectan a servicios externos, como las apps móviles con WebView y los scripts automáticos, porque suelen quedarse atrás. Quien desarrolla en macOS debe seguir con atención las instrucciones indicadas por Cloudflare. Si tienes un hosting con actualizaciones de seguridad gestionadas, verifica con el proveedor el estado del parche. El tema también afecta a quien usa certificados para la firma digital.
Nuestra opinión
El dato más alarmante no es el fallo, sino la lentitud de las actualizaciones. Una clave que cualquiera puede reconstruir es un error enorme, y que más de la mitad de las sondas siga aceptando la cadena muestra un problema más amplio – el software que nadie actualiza. El caso recuerda lo mucho que pesan las claves criptográficas, como en el malware KeyDrift en Cisco SD-WAN. Queda además una duda sobre el sistema de control, porque las auditorías y el cross-signing no detuvieron nada.
Preguntas frecuentes
¿Qué son las claves débiles de eMudhra?
Son ocho claves intermedias de una CA, generadas con números pequeños como 4 o 56. Por eso cualquiera puede reconstruirlas a partir de los certificados públicos y firmar certificados falsos.
¿Se ha visto comprometido Cloudflare?
Según Cloudflare, no hay pruebas de interceptaciones de sus conexiones. Los sistemas de alta prioridad se han actualizado y quedan pocos tickets de bajo impacto.
¿Cuál es el riesgo para un sitio o una aplicación?
Depende del cliente. Un cliente no actualizado y sin control de Certificate Transparency puede aceptar certificados falsos para cualquier dominio, lo que permitiría una posible interceptación.
¿Qué programas siguen más expuestos?
Los bots, los navegadores antiguos y los navegadores integrados como Android WebView. En estos últimos, según Cloudflare, entre el 30 y el 40 % sigue aceptando la cadena comprometida.
¿Qué debo hacer ahora?
Actualiza tus sistemas y sigue las instrucciones del sitio mantenido por Dennis Jackson, citado por Cloudflare. Si desarrollas en macOS, da prioridad a esas indicaciones.
Qué vigilar en las próximas semanas sobre el caso eMudhra
El caso está abierto en dos frentes, las explicaciones de eMudhra y el ritmo de las actualizaciones. Conviene seguir ambos.
- Comprueba si eMudhra publica el script de generación de claves y las conclusiones sobre auditorías y cross-signers.
- Sigue las actualizaciones de los navegadores y runtimes que usan tus aplicaciones, en particular los WebView.
- Verifica en los registros de tus servidores posibles certificados con nombres de dominio que no coincidan con los solicitados.
