El 19 de octubre de 2026 se descubrieron claves privadas intermedias de la autoridad de certificación eMudhra que eran extraordinariamente débiles. Cloudflare detalla ahora cómo detectó intentos de explotación, las medidas de mitigación aplicadas a sus sistemas y el estado del parcheo entre visitantes y bots.
Qué ocurrió y por qué importa
Las claves comprometidas o mal generadas de una CA permiten a terceros crear certificados fraudulentos que algunos clientes aún podrían aceptar. En este caso, Cloudflare describe que las claves filtradas eran lo suficientemente débiles como para recuperarse rápidamente desde los certificados públicos; eso significa que cualquier persona con acceso a esos certificados podía recrear las claves y firmar certificados para dominios ajenos.
Acciones inmediatas de Cloudflare
Cloudflare comenzó a parchear sistemas de alto impacto el 19 de octubre, priorizando los proxies de salida que gestionan la mayoría de las conexiones TLS salientes. Añadieron lógica para rechazar certificados firmados por las claves vulnerables y desplegaron registro (logging) específico en su servicio Pingora para detectar cuando alguien presentara certificados con esas claves.
También emplearon un análisis asistido por IA para localizar en su código las partes que confiaban en esos intermedios y asignaron tickets para confirmar y remediar cada caso. El registro comenzó a desplegarse por completo alrededor del 21 de octubre.
Evidencia de intentos de explotación
En la semana siguiente al parcheado, Cloudflare registró decenas de miles de intentos de handshake con las claves débiles. Aproximadamente dos tercios fueron conexiones a sitios de prueba que la propia Cloudflare había mencionado como referencia en su orientación técnica; gran parte del resto eran orígenes que aparentemente habían generado certificados usando una de las claves vulnerables.
Unos centenares de handshakes destacaron porque los certificados presentados contenían Subject Alternative Names (SANs) que nombraban dominios distintos al SNI de la conexión. Algunos parecen corresponder a certificados autogenerados por dispositivos o servidores (por ejemplo, IoT) y no a intentos de interceptación en el trayecto: se presentaban desde múltiples localizaciones y habrían fallado la verificación de nombre de host.
Cloudflare no ha encontrado pruebas de que las claves se hayan usado para interceptar sus propias conexiones; no obstante, sí existen certificados fraudulentos firmados con las claves débiles apareciendo pocas horas después de que la debilidad fuese pública, lo que demuestra que la creación de forgeries fue inmediata.
Cómo comprobó el estado de confianza en visitantes
Para estimar cuántos visitantes aún confiaban en las claves afectadas sin romper conexiones, Cloudflare añadió dos sondeos (probes) en páginas de desafío: uno usando un certificado firmado por eMudhra (vulnerable) y otro como control. Con decenas de millones de probes recogidos, los resultados muestran que navegadores modernos y actualizados están mayoritariamente parcheados, mientras que bots, navegadores antiguos y webviews embebidos (por ejemplo, Android WebView) presentan tasas más altas de aceptación de los certificados débiles.
Los datos están condicionados por la composición del tráfico: muchas peticiones a las páginas de desafío son automatizadas y sólo los clientes que ejecutan JavaScript envían los probes, por lo que las cifras no equivalen a una medición universal del parque de clientes.
Qué deben hacer administradores y propietarios de sitios
- Revisar y actualizar clientes TLS: asegúrese de que navegadores, librerías y componentes embebidos (WebView) estén actualizados para que no confíen en los intermedios comprometidos.
- Comprobar certificados propios: verifique que su CA emisora no depende de los intermedios afectados por eMudhra; si identifica certificados firmados por esos intermedios, reemítalos con un emisor confiable y contemporáneo.
- Habilitar Certificate Transparency y verificación estricta de nombres: esto reduce el riesgo de aceptar certificados forjados.
- Monitorizar logs y tráfico TLS: busque certificados inusuales, SANs que no coincidan con el SNI o handshakes repetidos desde orígenes distintos.
Cloudflare propone además investigar a fondo las causas del fallo en la generación de claves por parte de la CA y la cadena de auditoría que permitió que certificados débiles llegaran a producción. Mientras se clarifican responsabilidades, la recomendación práctica es comprobar actualizaciones de software y renovar certificados potencialmente afectados.
Lee también:
- Kernel Linux crítico (CVE-2026-98432): kernels parcheados en pruebas para AlmaLinux
- CVE-2026-98432: fallo use-after-free en TCP IPv4 del kernel afecta a CloudLinux (excepto 7)
Fuente: Cloudflare Blog
