Vulnerabilidad de eMudhra CA: ocho claves privadas, y una de ellas es el 4

‍TL;DR

eMudhra, una autoridad de certificación en la que confían todos los principales navegadores, generó las claves privadas de ocho de sus certificados de firma de tal forma que una de ellas es simplemente el número 4, lo más fácil de adivinar que puede ser una clave. Para encontrar una clave generada correctamente se necesitan unas 10^115 intentos. Estas claves requerían como máximo 256 intentos, lo suficiente para que cualquiera que pueda interceptar tu tráfico se haga pasar por cualquier sitio web.

• ¿A quién afecta?: Los navegadores ya han bloqueado los certificados. Los servidores, los procesos de integración continua (CI), las imágenes de Docker y las herramientas de línea de comandos como curl y git pueden seguir confiando en ellos, ya que nunca comprueban si un certificado ha sido revocado.
• Qué hacer: actualiza tu paquete de certificados de autoridad (CA) y vuelve a compilar tus imágenes. A continuación se indican los pasos a seguir.
• Cómo ayuda Aikido: Aikido marca como problemas «críticos» o «graves» las imágenes de contenedores que aún contienen los paquetes de certificados afectados.

Quiénes están afectados

La mayoría de los usuarios de navegadores están protegidos. Firefox y Chrome han bloqueado los certificados desde el 17 de octubre, los dispositivos de Apple desde el 19 de octubre y las plataformas de Microsoft desde el 20 de octubre, utilizando las listas de revocación que sus proveedores envían a los usuarios.

Los ocho certificados afectados son autoridades de certificación intermedias, es decir, certificados de firma que forman parte de una cadena que conduce a una raíz de confianza. Quien posea la clave privada de una autoridad intermedia puede firmar un certificado válido para cualquier dominio. Estos ocho forman parte de una cadena que conduce a «emSign ECC Root CA - G3», que Mozilla ha eliminado de su almacén de confianza y que Chrome tiene previsto hacer lo mismo el 27 de octubre.

La vulnerabilidad se encuentra en un programa que realiza su propia comprobación de certificados:

• Herramientas de línea de comandos. En macOS, la función integrada curl, git, python3, Perl, rubí y openssl comparar con /etc/ssl/cert.pem sin comprobar si ha sido revocado, y ese archivo no se actualiza automáticamente. El contenido de ese archivo y, por consiguiente, tus herramientas de Linux dependen de la certificados CA paquete de tu distribución.
• Contenedores e integración continua. Una imagen incluye el paquete de certificados de autoridad (CA) con el que se creó. Muchas imágenes siguen incluyendo el antiguo.
• Entornos de ejecución de lenguajes. Go, Java, Node.js y Python certifi, «webpki-roots» de Rust y otros incluyen sus propias raíces, y cada uno requería su propia versión.
• IoT: Los dispositivos del Internet de las cosas incluyen certificados CA en su firmware y, debido a la dificultad para actualizarlos, es probable que sigan siendo vulnerables durante años.
• Firma de código. Seis de los ocho certificados intermedios eran para TLS y dos eran autoridades de certificación (CA) de firma de código de confianza de Microsoft, por lo que un atacante también podría firmar malware con el nombre de cualquier editor. Microsoft los ha bloqueado desde el 20 de octubre.

El uso de un certificado falsificado sigue requiriendo un punto de acceso en la ruta de red, como una red Wi-Fi hostil o un router comprometido. La web dedicada al incidente también informa de que los ocho certificados intermedios no aparecían en los registros de transparencia de certificados antes del bloqueo, por lo que los clientes que aplican la transparencia (Firefox, Chrome, Edge y Safari) no podrían haber sido atacados. Los clientes que no la aplican podrían haber sido objeto de ataques, y la web afirma que desconoce si los atacantes utilizaron las claves defectuosas contra ellos.

¿Qué hacer ahora?

1. Actualiza tu sistema operativo y tus navegadores. Esto es válido para la mayoría de los usuarios.
2. Actualiza el paquete de certificados de autoridad (CA) en los servidores y en las imágenes. El parcheado certificados CA La versión depende de tu distribución: Ubuntu incluye 20260816ubuntu0.*, Debian 12 sale al mercado 20250419~deb12u2, Barcos Alpine 20261020-r0, Fedora incluye 2026.2.92_v9.0.319. Si se utiliza un único criterio de corte de versión, algunos de estos casos se clasificarán erróneamente, así que comprueba el tabla del lugar del incidente para su distribución y su entorno de ejecución. Vuelva a generar el almacén de confianza activo cuando su distribución lo requiera.
3. Recrea las imágenes y reinicia los servicios. Descarga una imagen base nueva (docker build --pull --no-cache) para que se incorpore el paquete actualizado. Ten en cuenta que aún no se han actualizado todas las imágenes. Un contenedor en ejecución conserva la versión anterior.
4. Pruébalo. Ejecuta los dos comandos que aparecen a continuación. El resultado que debes obtener es un error de SSL con el código HTTP 000.
5. Ocúpate de los rezagados. En cuanto a las herramientas integradas de macOS, que Apple aún no ha actualizado, la página web dedicada al incidente publica comandos de solución alternativa. Entornos de ejecución integrados como Node.js, Go, Java y certifi Cada una necesita su propia versión parcheada.

curl -sS -o /dev/null -w "HTTP %{http_code}\n" https://dv-g3b-emudhra.we-have-a-problem.com/
curl -sS -o /dev/null -w "HTTP %{http_code}\n" https://dv-g3b-aaa-emudhra.we-have-a-problem.com/

Un cliente que ya no confía en los certificados intermedios comprometidos rechaza ambas solicitudes con un error SSL y muestra el siguiente mensaje: HTTP 000:

curl: (60) Problema con el certificado SSL: no se ha podido obtener local certificado del emisor
HTTP 000

A 200 significa que el cliente sigue confiando en ellos.

Para saber cuál certificados CA Versión que tienes:

dpkg -s ca-certificates | grep Version   # Debian, Ubuntu
apk info ca-certificates                 # Alpine
rpm -q ca-certificates                   # Fedora, RHEL

Cómo ayuda el aikido

Si eres cliente de Aikido, las imágenes de contenedores se comprueban automáticamente. La comprobación abarca tanto los paquetes que incluyen sus propios conjuntos de certificados como el almacén de confianza proporcionado por el sistema, y se genera un informe de incidencia independiente para cada uno de ellos.

En el caso de los paquetes que cuentan con su propio paquete, como «certifi» de Python anterior a la versión 2026.10.18, la imagen recibe una clasificación de «Crítica». En cuanto al almacén de confianza del sistema, que sigue aceptando cadenas a través de los intermedios comprometidos, recibe una clasificación de «Alta». Cada problema viene acompañado de una solución que se ajusta a los pasos anteriores, y las aplicaciones que incorporan sus propias raíces necesitan actualizaciones independientes.

También hemos lanzado Device Protection v1.10.20 como corrección para este problema. Si utilizas Device Protection, te recomendamos que actualices a esta versión.

Qué pasó: ocho teclas, y una de ellas es la 4

eMudhra es una autoridad de certificación con sede en la India: comprueba quién gestiona un sitio web y emite el certificado que aparece detrás del candado del navegador, y los programas raíz de Firefox, Chrome, Apple y Microsoft confían en ella. Una autoridad de certificación intermedia es un certificado de firma que se vincula a una de esas raíces de confianza, y quien posea su clave privada puede firmar un certificado válido para cualquier dominio.

El 17 de octubre, un investigador conocido como Wayne informó a los equipos responsables de los programas raíz de los navegadores y los sistemas operativos de que las claves privadas de ocho certificados de la autoridad de certificación intermedia de eMudhra se habían visto comprometidas. Para demostrarlo, Wayne firmó el mensaje«Tenemos un problema aquí» con cada una de las ocho claves. Los certificados datan de abril de 2025. eMudhra generó las claves de forma incorrecta, lo que significa que cualquiera puede recuperarlas a partir de los certificados públicos.

Una clave privada es un número secreto que debe ser imposible de adivinar. Una clave de este tipo generada correctamente se selecciona de un rango de aproximadamente 10^115 valores, es decir, un 1 seguido de 115 ceros. Según el análisis de nuestro equipo, cada una de estas ocho claves es inferior a 256, y una de ellas es el 4.

Una posible explicación para los valores tan pequeños sería un error clásico de conversión de tipos, en el que el número aleatorio grande se convirtiera accidentalmente a un byte. Otra teoría apuntaba a un antiguo comportamiento de Go, en el que una conversión decimal truncaba el número a un solo byte.

El cuatro es también el número del xkcd 221, en el que una función de números aleatorios devuelve un 4 y un comentario asegura que se eligió lanzando un dado imparcial. Un atacante necesitaba como máximo 256 intentos para dar con cualquiera de las ocho claves, frente a los aproximadamente 10^115 que debería haber necesitado, y un ordenador portátil puede probar las 256 antes de que termines esta frase. Un candado de bicicleta de tres dígitos tiene 1.000 combinaciones, por lo que el candado de tu bicicleta le da más trabajo a un ladrón que estas claves le dieron a un atacante.

Por qué los navegadores están arreglados y puede que curl no lo esté

Mozilla, Google, Apple y Microsoft distribuyen información sobre revocaciones a sus navegadores a través de mecanismos como OneCRL, CRLite y CRLSets, de modo que se puede bloquear un certificado intermedio no válido sin tener que esperar a una actualización de software. eMudhra también revocó los certificados, pero solo un cliente que compruebe la revocación puede detectarlo.

La mayoría de las herramientas de línea de comandos y los entornos de ejecución no realizan comprobaciones. Mantienen una lista de certificados raíz de confianza y aceptan cualquier certificado que forme parte de una cadena que conduzca a uno de ellos, por lo que la única forma de evitar que confíen en un certificado intermedio comprometido es distribuir una nueva lista. Según el sitio web dedicado a este incidente, muchos clientes ajenos al ecosistema de los navegadores ignoran por completo los datos de revocación, por lo que solo una actualización de software les protege.

macOS es el ejemplo más claro. Los dispositivos de Apple bloquean los certificados a nivel del sistema operativo, pero el comando «curl» integrado lee /etc/ssl/cert.pem, que no se ha actualizado en absoluto. Un navegador y un terminal instalados en el mismo ordenador portátil pueden discrepar sobre si un mismo certificado es válido.

Los contenedores añaden un retraso propio. Una imagen de Docker congela su paquete de CA en el momento de la compilación, por lo que todas las imágenes compiladas antes de la corrección, y todas las imágenes compiladas a partir de una capa base antigua desde entonces, siguen confiando en los archivos intermedios comprometidos hasta que alguien las vuelva a compilar. Algunos ejemplos a fecha de 22 de octubre son: grafana/grafana:última versión, mysql:última versión, jenkins/jenkins:última versión & bitnami/postgresql:última versión.

Cómo funciona la confianza en los certificados, en pocas palabras

Un certificado es la tarjeta de identificación digital de un sitio web. Cuando abres un sitio HTTPS, el servidor envía su certificado y tu cliente comprueba que el nombre coincida con el del sitio, que las fechas sean válidas y que la firma proceda de una entidad en la que confía.

El firmante es una autoridad de certificación (CA). Tu sistema operativo o navegador incluye de serie una lista integrada de CA raíz en las que confía. Las CA raíz permanecen fuera de línea y delegan el trabajo diario a las CA intermedias, que firman los certificados que utilizan realmente los sitios web. Se acepta un certificado cuya cadena de certificación pasa por una CA intermedia hasta llegar a una CA raíz de confianza.

La clave privada de un certificado intermedio puede firmar un certificado válido para cualquier dominio, por lo que, si se filtra una clave, se transfiere la autoridad de la raíz hasta que se indique a los clientes que dejen de confiar en ella.

Cronología

Actualizaciones y fuentes

22 de octubre de 2026: Publicado por primera vez. El estado de los parches cambia a diario, así que consulta la tabla del sitio web de incidencias correspondiente a tu distribución y entorno de ejecución.

Fuentes:

• eMudhra Intermediate CA Compromise, página sobre el incidente gestionada por Dennis Jackson y otros colaboradores
• Informe de incidentes de Mozilla, tal y como aparece en el enlace de la página de incidentes