Revisado por Iván Quintas, Editor de IA News
eMudhra: la CA comprometida que obliga a parchear pip, uv y certifi
Ocho intermedios de eMudhra con claves comprometidas permiten MITM. pip 26.2.2, uv 0.13.4+ y certifi 2026.10.19 ya quitan la root emSign de sus bundles.

Si desarrollas en Python, hoy toca lo mismo que esta semana en PHP y Node.js: parchear. La diferencia es que aquí nadie ha roto código — han roto la confianza. Las claves privadas de ocho certificados intermedios de la autoridad certificadora eMudhra están comprometidas, y esa root figuraba en los bundles de CAs que pip y uv llevan vendados dentro. Resultado: hasta parchear, tus instaladores de paquetes aceptaban certificados de un atacante para cualquier hostname.
Las versiones que arreglan ya están fuera: pip 26.2.2 (20 de octubre), uv 0.13.4 y mejor 0.13.5 (20 y 21 de octubre), y certifi 2026.10.19.
Qué ha pasado
El 17 de octubre, un investigador identificado como Wayne demostró el compromiso de la forma más contundente posible: firmó un mensaje con la clave privada de cada uno de los ocho intermedios y lo reportó a los equipos de los root programs. El sitio del incidente, emudhra.we-have-a-problem.com, publica el mensaje, los certificados y las firmas — cualquiera puede verificarlo con OpenSSL. “We have a problem here”, dice el mensaje firmado. Y lo firmó ocho veces con ocho claves que no debería tener.
Los ocho intermedios encadenan a la root emSign ECC Root CA - G3, incluida en los programas de root de Mozilla, Microsoft, Apple y Chrome. La cronología del bloqueo:
- 17 de octubre — Firefox y Chrome bloquean los certificados.
- 19 de octubre — disclosure responsable a los trust stores downstream; Apple bloquea en sus dispositivos.
- 20 de octubre — Microsoft bloquea en sus plataformas; se publica el sitio del incidente; salen certifi 2026.10.19, pip 26.2.2 y uv 0.13.4.
La consecuencia, en palabras del propio sitio del incidente: un atacante con cualquiera de esas claves puede suplantar cualquier sitio web o servicio. No es un bug de un producto: es la infraestructura de confianza de HTTPS con una llave maestra en manos equivocadas.
Por qué Python va en el primer pelotón
El problema no lo causa Python — lo causan los bundles de CAs vendados. Las herramientas de instalación no usan el almacén del sistema operativo: llevan su propia lista de CAs dentro.
- uv verifica TLS contra
webpki-root-certs, que incluía la root emSign. El advisory GHSA-hq85-5cpj-mr62 lo puntúa crítico (CVSS v4.0 9.1, CWE-295): un atacante podía emitir certificados que uv aceptase para cualquier hostname. - pip lleva
certifiempaquetado, y elensurepipde las distribuciones de Python también.
Y el vector importa: si tu instalador de dependencias acepta un certificado del atacante, un man-in-the-middle puede servirte código malicioso en una instalación. El mismo canal que descarga tus paquetes es el de ataque.
La cadena de parches
El orden en que se cerró cada eslabón:
- certifi 2026.10.19 (20 de octubre) — advisory crítico, quita la root emSign del bundle.
- pip 26.2.2 (20 de octubre) — el changelog lo dice en una línea: “Upgrade certifi to 2026.10.19”.
- uv 0.13.4 (20 de octubre) — elimina la root de su store vía
webpki-root-certs1.0.10. - uv 0.13.5 (21 de octubre) — repina sus Pythons gestionados a
python-build-standalone20261020, que instalan pip 26.2.2 y empaquetan el mismo wheel enensurepip: ambos caminos quedan con certifi 2026.10.19.
En tu terminal:
# uv: 0.13.4 mínimo, 0.13.5 recompila los Pythons gestionados
uv self update
uv python upgrade # repite tras actualizar uv
# pip: 26.2.2+, en cada venv y en el Python del sistema
python -m pip install --upgrade pip
# certifi en tus proyectos
python -m pip install --upgrade certifi
No es solo Python
El advisory de uv lo dice sin rodeos: “uv is not the only impacted package. You MUST evaluate your other packages”. Todo lo que empaqueta bundles de CAs — certifi, webpki-root-certs, cualquier app que los meta dentro — necesita la misma revisión.
La prueba la tienes en la propia sección: los security releases de Node.js de este mismo mes ya retiraban el intermedio de eMudhra comprometido, listado explícitamente entre los motivos del release. Y si usas uv con --system-certs o un bundle propio vía SSL_CERT_FILE, el advisory te pide confirmar que ese almacén tampoco contenga los intermedios revocados.
El contexto
La semana del stack se está componiendo sola: PHP con dos RCE críticas el miércoles por la mañana, Node.js con diez CVEs por la tarde, y ahora una CA comprometida que atraviesa ecosistemas. Tres historias distintas, un mismo patrón: el software se parchea en oleadas, y el que tiene el inventario hecho es el que duerme.
El detalle que más debería incomodar no es eMudhra: es que tu HTTPS vale exactamente lo que valga el bundle de CAs que tu herramienta lleva dentro. Las actualizaciones del sistema operativo no te salvan si el certificado de confianza va vendado en un wheel. La cadena tiene eslabones que no ves hasta que alguien los firma con la clave equivocada — y el 17 de octubre, Wayne firmó ocho.
¿Te ha servido? Márcanos como fuente preferida en Google y verás antes nuestros artículos en Noticias destacadas, AI Overviews y AI Mode.
📎 Fuente original: X / @L4UR3N7 ↗