Ocho claves privadas que cualquiera podía calcular
El 20 de octubre de 2026 se hizo público que ocho certificados intermedios de eMudhra, una autoridad certificadora india, tenían sus claves privadas expuestas. Lo llamativo no es que se filtraran: es que nunca hicieron falta. Las claves se generaron con tan poca aleatoriedad que cualquiera podía recalcularlas a partir del certificado público.
Una de esas claves privadas era literalmente el número 4. Las otras eran 56, 66, 115, 155, 156, 230 y 237, según The Next Web. El investigador Scott Helme recuperó las ocho desde su laptop en menos de un segundo, reportó The Hacker News.
Con una de esas claves, un atacante puede emitir un certificado válido para cualquier dominio y presentarlo ante clientes que confíen en la cadena de eMudhra. En la práctica: interceptar tráfico cifrado sin que la víctima lo note.
¿Y esto cómo se aplica en tu negocio?
En CAR, dueños de empresa de Latinoamérica y España usan la tecnología para ser más rentables. Empiezas con una ruta de 7 días y terminas con un sistema funcionando en tu negocio.
👥 Probar 7 díasLa carrera de 48 horas: quién parcheó qué
El reporte llegó a los root programs el 17 de octubre por la tarde, firmado por un investigador identificado solo como Wayne. Chrome recibió el aviso a las 18:05 UTC y ya tenía bloqueados los seis intermedios TLS a las 19:45 UTC. Mozilla recibió a las 20:06 y terminó de empujar el bloqueo OneCRL a las 22:59. Ninguno de los dos necesitó que el usuario actualizara o reiniciara nada.
Apple bloqueó el 19 de octubre, Microsoft el 20, y los dispositivos Android recibieron el bloqueo vía Google Play Services el 19. Go publicó las versiones 1.27.3 y 1.26.10 (CVE-2026-111943) el 20 de octubre. También sacaron correcciones Python certifi, Rust webpki-roots, Homebrew, Composer y Cloudflare. Node.js, Bun y FreeBSD seguían pendientes.
Queda un plazo que conviene anotar: Chrome retirará la raíz emSign ECC Root CA - G3 de su root store el 27 de octubre, así que los sitios que todavía cuelgan de esa jerarquía necesitan un certificado de otra autoridad antes de esa fecha para no romperse.
eMudhra atribuyó el fallo a su ceremonia de generación de claves del 30 de abril de 2025: un paso de wrap/unwrap produjo un segundo juego de claves débiles que terminó siendo el publicado en los root stores. La empresa sostuvo que su infraestructura no fue comprometida y que su negocio global de TLS representa alrededor del 1% de sus ingresos. Sus acciones cayeron hasta un 20% en Mumbai el 21 de octubre, según CNBC-TV18.
Por qué tu MCU probablemente se salvó
Acá está el punto que le importa a quien construye hardware. La razón es de recursos: un microcontrolador típico tiene menos de 1 MB de almacenamiento no volátil, a veces mucho menos. Cargar un bundle de raíces X.509 de varios cientos de kilobytes simplemente no cabe.
Por eso el firmware suele fijar una o dos raíces concretas. El ejemplo que da el autor del análisis original: el sample HTTP GET de Zephyr RTOS que se conecta a google.com incluye un único certificado raíz —el de GlobalSign— de casi 1 KB en DER. No hay bundle genérico ni programa de raíces mantenido por un tercero.
Hay un segundo filtro que también ayuda: los navegadores exigen Certificate Transparency y los clientes embebidos casi nunca. Eso implica que un ataque contra un MCU no dejaría rastro en los logs públicos, pero también que el atacante necesita que el dispositivo confíe en la cadena de eMudhra para que el certificado falso le sirva.
La conclusión práctica: si tu MCU no se conecta a un servidor cuya cadena de confianza esté anclada en una raíz de eMudhra, y no incluiste esa raíz —ni la de Sectigo usada para cross-signing— en el firmware, tus dispositivos quedaron fuera de este incidente.
¿Qué significa esto para tu startup?
Tres lecturas que cambian según lo que construyas.
La distinción entre "IoT" y "MCU" no es semántica. Un Raspberry Pi, o cualquier cosa que corra Linux, es un cliente TLS completo: tiene bundle de raíces, capacidad de OTA y, con frecuencia, ninguna verificación de revocación. Ahí sí aplica la advertencia de que los dispositivos quedan expuestos. Filippo Valsorda, mantenedor de los paquetes de criptografía de la librería estándar de Go, lo resumió a Ars Technica: "Será un trabajo de limpieza masivo, más grande que Heartbleed. Habrá una cola muy, muy larga: dispositivos IoT, contenedores Docker, máquinas Linux olvidadas, herramientas CLI sin mantenimiento que traían su propia copia de las raíces."
El riesgo inmediato está en tu stack de desarrollo, no en tu producto. Go, Python, Node, contenedores, pipelines de CI. Yash Kadakia, fundador y CTO de Security Brigade, estimó que unos 30.000 certificados legítimos tendrían que migrar, y advirtió que los equipos de seguridad deben revisar pasarelas de pago, integraciones con proveedores, aplicaciones Java antiguas, apps móviles y appliances de red, que usan trust stores separados de los de los navegadores.
El incidente ya tiene dimensión regulatoria. CERT-In emitió una alerta urgente y el Ministerio de Electrónica y Tecnología de India (MeitY) conformó un equipo especial para investigar, según CNBC-TV18. Para una startup que vende a gobierno o banca en India, eso se traduce en cuestionarios de seguridad y auditorías adicionales.
Qué hacer esta semana
- Inventario de trust stores. Lista cada lugar donde tu producto valida un certificado: navegador, app móvil, backend, contenedores, jobs de CI. Los que no consultan revocación seguirán confiando en la cadena hasta que cambies el código o el bundle.
- Rebuild, no solo update. El filtro de Go vive en la librería estándar y rechaza cualquier cadena que contenga una de las ocho claves, pero solo se aplica cuando recompilas con la versión nueva. Actualizar el binario no basta si el build quedó viejo.
- Revisa contenedores e imágenes base. Muchos equipos actualizaron el host y se olvidaron de las imágenes que corren en producción. Cloudflare advirtió que los clientes que corren sus propios origin servers, mutual TLS o contenedores pueden necesitar actualizar sus trust stores a mano.
- Documenta las raíces fijadas en tu firmware. Si haces MCU, ten un registro de qué raíces están pinneadas, por qué y quién las revisa. Ese inventario es lo que te permite responder en minutos la próxima vez que reviente una CA.
- No mezcles amenazas. El fallo no afecta a Signal, WhatsApp ni WireGuard, que no dependen de TLS para la confidencialidad, según Ars Technica.
La lección de fondo
El autor del análisis original cierra con una observación que vale para cualquier equipo de producto: hay algo valioso en un sistema que solo hace un conjunto fijo y bien definido de tareas. Un MCU no puede permitirse confiar en 150 raíces, así que obliga a decidir explícitamente en quién confía. Esa intención —menos superficie, menos dependencias, decisiones documentadas— es exactamente lo que le faltó al resto del ecosistema, donde un bundle de raíces se actualiza solo y nadie recuerda qué hay adentro.
Conclusión
El compromiso de eMudhra es un recordatorio de que la confianza en internet se apoya en un puñado de organizaciones que casi nadie audita. Para un founder, la lectura no es "los MCU están a salvo y ya": es que la seguridad de tu producto depende de decisiones que tomaste hace años y que probablemente nadie documentó. Esta semana toca parchear el stack. Este trimestre toca escribir el inventario.
Fuentes
- Your MCU Likely Escaped the eMudhra Intermediate CA Compromise (fuente original)
- Eight eMudhra CA Keys Compromised, Triggering Emergency Fixes Across Browsers and Software
- Mozilla, Google, Apple block compromised eMudhra CA certificates
- Google, Mozilla revoke eMudhra intermediates after private key compromise
- Eight eMudhra certificate keys were so weak that one was the number 4
- CERT-In issues urgent alert on eMudhra; MeitY forms team to investigate
¿Y esto cómo se aplica en tu negocio?
En CAR, dueños de empresa de Latinoamérica y España usan la tecnología para ser más rentables. Empiezas con una ruta de 7 días y terminas con un sistema funcionando en tu negocio.
👥 Probar 7 días
