El 20 de octubre de 2026, se confirmó un compromiso crítico que afecta las claves privadas de ocho certificados intermedios emitidos por la Autoridad Certificadora (CA) eMudhra. Estos certificados comprometidos se encadenan a raíces de confianza incluidas por defecto en los programas de Mozilla, Microsoft, Apple y Chrome, así como en múltiples almacenes de confianza (trust stores) de otros sistemas. La CA ha revocado los certificados y los principales ecosistemas de navegadores web desplegaron bloqueos rápidos (entre el 17 y el 22 de octubre). Sin embargo, el riesgo de explotación persiste de manera crítica para herramientas, lenguajes de programación y clientes fuera del entorno de los navegadores que no consumen listas de revocación ni verifican la Transparencia de Certificados (CT).
Análisis Técnico y Vectores de Riesgo
El incidente tiene su origen en una falla de seguridad operativa por parte de la CA: las claves privadas para estos certificados intermedios fueron generadas incorrectamente. Este fallo algorítmico permite que cualquier actor malicioso pueda derivar y recuperar la clave privada directamente a partir del certificado público.
- Riesgo de Intercepción (MITM): Un atacante en posesión de cualquiera de las claves privadas de estos CAs intermedios puede generar certificados TLS/SSL fraudulentos y suplantar la identidad de cualquier sitio web o servicio a nivel global.
- Vector de Transparencia de Certificados (CT): Los certificados existen desde abril de 2025. Los navegadores modernos (Chrome, Edge, Safari, Firefox) no eran vulnerables a ataques silenciosos porque exigen que los certificados estén registrados en los logs de Transparencia de Certificados (CT), y los certificados maliciosos generados no contaban con este registro.
- Superficie de Ataque Actual: El peligro inminente recae en clientes no-navegador (non-browser clients). Herramientas como curl, gestores de paquetes (pip, Composer), lenguajes de ejecución (Python, Node.js, Java, Go) y scripts de automatización no suelen imponer el requisito de CT ni verificar listas de revocación de forma estricta. Un atacante puede utilizar estas claves para interceptar y alterar tráfico API o descargas de dependencias de software.
Plan de Mitigación Operativa y Respuesta
- Actualización de Almacenes de Confianza (SO y Contenedores): Actualizar urgentemente los paquetes de certificados raíz en todas las distribuciones de Linux (ej. ca-certificates en Debian/Ubuntu/Alpine) y sistemas operativos a las versiones parcheadas emitidas a partir del 20 de octubre de 2026. Es crucial reconstruir las imágenes de contenedores (Docker) para que hereden los nuevos almacenes.
- Actualización de Runtimes y Librerías de Lenguajes: Los equipos de desarrollo deben actualizar de inmediato los entornos de ejecución que manejan sus propios almacenes de confianza. Esto incluye actualizar Node.js (a 26.12.1, 24.22.1 o 22.23.4), Python (3.15.1, 3.14.9, 3.13.17, o su librería certifi), Java (OpenJDK/Oracle JDK), Go y herramientas como curl.
- Despliegue de Mitigaciones Manuales (Workarounds): Para sistemas que no puedan recibir parches de inmediato, se deben deshabilitar manualmente las raíces afectadas (“Comodo AAA Services root” y “emSign ECC Root CA – G3”) de los almacenes del sistema.
- Linux: Utilizar herramientas nativas como trust extract con listas de bloqueo (blocklists) o editar /etc/ca-certificates.conf.
- Windows: Confirmar que los equipos reciben actualizaciones automáticas de listas de confianza de certificados (CTL). Para servidores aislados u offline, los administradores de TI deben inyectar localmente los 16 intermedios a la carpeta de “Certificados no confiables” mediante el script de PowerShell proporcionado por la comunidad.
