Certificados de eMudhra comprometidos: qué actualizar en servidores, contenedores y lenguajes

Ocho certificados intermedios de la autoridad eMudhra tenían claves privadas recuperables. Los navegadores ya los bloquean; servidores, contenedores, Python, Java, Go y Node.js necesitan actualizarse. Cronología, alcance y comprobación.

Por Equipo Xterra Engine 22 de octubre de 2026 4 min de lectura

Incidente de certificados intermedios comprometidos de eMudhra, 17 al 21-10-2026

El 17 de octubre de 2026 un investigador informó a los programas de raíces de confianza que ocho certificados intermedios de la autoridad certificadora eMudhra tenían claves privadas que podían deducirse de los propios certificados públicos. Quien tenga una de esas claves puede emitir un certificado válido para cualquier dominio. Los navegadores bloquearon los certificados en pocas horas; el riesgo que queda está en el software que no es un navegador. Este artículo explica el mecanismo, reúne la cronología y ordena qué actualizar en servidores, contenedores y entornos de programación.

Explicación para quien no administra servidores

Cuando un programa se conecta a un sitio seguro (HTTPS), comprueba que el certificado del sitio esté firmado por una autoridad en la que confía. Es como verificar un documento de identidad por el sello de quien lo emitió. Si el sello de un emisor se puede falsificar, cualquiera puede fabricar identidades que parecen legítimas.

Eso ocurrió con ocho «sellos» intermedios de eMudhra. Chrome, Firefox, Safari y Edge ya los rechazan. Pero muchos sistemas de empresa, como integraciones entre aplicaciones, scripts, contenedores, equipos y dispositivos, usan su propia lista de autoridades de confianza y no se enteran solos. Mientras esa lista no se actualice, alguien con acceso a la red intermedia podría hacerse pasar por un servicio legítimo y leer o alterar la información.

Mecanismo del compromiso

Según el análisis de Aikido, eMudhra generó incorrectamente las claves de los ocho intermedios: todas son números menores que 256, cuando una clave correcta exige del orden de 10¹¹⁵ intentos para encontrarla. Seis intermedios emiten certificados TLS y dos firman código. Los certificados se encadenan a la raíz emSign ECC Root CA - G3 y, mediante certificados cruzados, a la raíz AAA Certificate Services de Sectigo (Comodo), según Red Hat.

Un ataque requiere tres condiciones a la vez: que el sistema confíe todavía en esos intermedios, que el atacante tenga una de las claves y que pueda interceptar la conexión desde una posición intermedia de red, como una Wi-Fi hostil o un enrutador comprometido. Los clientes que exigen Certificate Transparency (CT), el registro público obligatorio de certificados, no eran atacables porque los intermedios no figuraban en CT antes del bloqueo. El registro ctlogs.dev documenta que, después del bloqueo, aparecieron en CT más de cien mil certificados emitidos con esas claves, la mayoría con nombres de dominios conocidos: el riesgo para clientes sin CT ni revocación es concreto.

Cronología

Fecha (2026)	Hecho
17 de octubre	Reporte a los programas de raíces. Chrome (CRLSet) y Firefox (OneCRL) bloquean los intermedios.
18 de octubre	eMudhra revoca los ocho intermedios.
19 de octubre	Sectigo revoca los certificados cruzados. Apple bloquea los intermedios. Go publica 1.27.3 y 1.26.10.
20 de octubre	Microsoft bloquea los intermedios. Divulgación pública. Mozilla retira la raíz emSign ECC Root CA - G3 (NSS 3.131.1).
21 de octubre	Node.js y Oracle Java (CVE-2026-91403) publican correcciones. Red Hat publica el boletín RHSB-2026-012.
27 de octubre	Fecha prevista para que Chrome retire la raíz emSign ECC Root CA - G3 de su almacén.

Qué clientes quedaron protegidos y cuáles dependen de una actualización: navegadores bloquean por listas de revocación y CT; sistemas operativos, contenedores, lenguajes con almacén propio y dispositivos necesitan actualizar su lista de confianza. — Los navegadores se protegieron solos; el resto depende de actualizar su lista de autoridades.

Qué actualizar, por capa

La regla práctica es identificar de dónde toma cada programa su lista de autoridades de confianza. Hay tres orígenes posibles: el sistema operativo, un archivo propio del lenguaje o un archivo congelado dentro de una imagen o un firmware.

Sistema operativo (Linux): actualizar el paquete ca-certificates. Aikido cita como corregidas, entre otras, Debian 12 20250419~deb12u2 y Alpine 20261020-r0; Red Hat publicará las versiones para RHEL en su boletín. Mientras tanto, Red Hat indica cómo desactivar las raíces afectadas (artículo 7149312).
Contenedores: reconstruir con docker build --pull --no-cache sobre una imagen base actualizada y redesplegar. Un contenedor en ejecución conserva la lista anterior.
Python: certifi trae su propia lista. Actualizarlo en cada entorno virtual con pip install --upgrade certifi; las fuentes sitúan la corrección en las versiones del 18 y 19 de octubre. requests y urllib3 dependen de él.
Go: actualizar a 1.27.3 o 1.26.10 y recompilar los binarios, porque la protección vive dentro del programa compilado (ver el artículo dedicado a Go).
Java: CVE-2026-91403. Las distribuciones de JDK independientes usan su propio cacerts y requieren la versión corregida o el archivo blocked.certs oficial (ver el artículo dedicado a Java).
Node.js: las versiones 22.23.4, 24.22.1 y 26.12.1 actualizan el almacén integrado. Con --use-openssl-ca, Node.js usa el del sistema.
Rust: las fuentes reportan que webpki-roots 1.0.10 retira la raíz; conviene comprobarlo en el registro de cambios del crate.
macOS en la línea de comandos: curl, git o python3 pueden usar /etc/ssl/cert.pem, que no se actualiza solo.
Dispositivos y firmware: según Aikido, los equipos que traen las autoridades en su firmware podrían seguir vulnerables por años; conviene preguntar al fabricante.

Procedimiento de verificación

Listar los clientes HTTPS que no son navegadores: integraciones, tareas programadas, agentes de monitoreo, ejecutores de CI y servicios que llaman a APIs.
Comprobar la versión de ca-certificates con dpkg -l ca-certificates, apk info -v ca-certificates o rpm -q ca-certificates.
En Python, ejecutar python -c "import certifi; print(certifi.__version__, certifi.where())" en cada entorno.
Probar el rechazo con los servidores de prueba que publica el sitio del incidente, emudhra.we-have-a-problem.com: un cliente protegido debe fallar con un error de certificado; una respuesta HTTP 200 indica que todavía confía en los intermedios.
Repetir la prueba desde dentro de cada contenedor, no solo desde el servidor que lo aloja.

Preguntas frecuentes

Si nuestro sitio no usa certificados de eMudhra, ¿hay algo que hacer?

Sí. El riesgo no está en el certificado propio, sino en que los sistemas de la empresa acepten certificados falsos de otros sitios. Afecta a quien se conecta, no a quien es visitado.

¿Hay evidencia de ataques?

Red Hat no reporta explotación activa. Sin embargo, la aparición masiva de certificados en CT después del bloqueo muestra que las claves circulan, así que conviene no esperar.

Fuentes

Red Hat, RHSB-2026-012.
Aikido, eMudhra CA Compromise.
ctlogs.dev, cronología e intermedios afectados.
Google, protección de Chrome y Android.
OpenJDK, aviso del 21 de octubre de 2026.

Revisión de clientes TLS

Xterra Engine inventaría los clientes HTTPS de una organización, identifica qué almacén de confianza usa cada uno y deja documentada la prueba de rechazo. Para solicitar la revisión o una cotización, escriba a info@xterraengine.com o use el formulario de contacto.