Desde el 17 de octubre de 2026 Apple sabe que los certificados eMudhra comprometidos siguen activos en las herramientas de macOS. Once días después, git, curl y python3 todavía confían en ellos: cualquiera que intercepte la conexión puede entregar código falso en un git clone o robar un token de GitHub en tránsito.
Peor aún: macOS 27.2, publicado el 26 de octubre, no corrigió el problema y además deshizo el workaround manual que muchos desarrolladores habían aplicado por su cuenta, dejándolos expuestos de nuevo sin aviso.
TL;DR
- Apple sigue sin corregir los certificados eMudhra comprometidos en git, curl y python3 de macOS (28 de octubre de 2026).- eMudhra notificó a Apple el 17 de octubre de 2026; macOS 27.2, lanzado el 26 de octubre, no aplicó el parche.- La actualización del 26 de octubre revirtió el workaround manual que los desarrolladores habían instalado.- Safari y las apps que usan el framework de red de Apple ya están protegidas; las herramientas CLI no.- Un comando
git ls-remotecontra un dominio de prueba revela si tu copia de git en macOS sigue vulnerable.
Qué es eMudhra
eMudhra es una autoridad certificadora con sede en India que emite certificados digitales X.509 para asegurar conexiones HTTPS en internet, dentro de la cadena de confianza que valida la identidad de un sitio web. En octubre de 2026, varios certificados intermedios de eMudhra quedaron comprometidos y exponen a los clientes que aún los validan.
Sus raíces y certificados intermedios están preinstalados en los almacenes de confianza de sistemas operativos y navegadores de todo el mundo, incluido macOS. Por eso el problema no se limita a India: cualquier conexión HTTPS que dependa de esas raíces queda en riesgo mientras sigan marcadas como válidas. En el ecosistema de confianza TLS, cuando una CA falla, la superficie de ataque no se limita a sus clientes directos, sino a cualquier sistema que todavía la liste como confiable.
Qué pasó con los certificados eMudhra comprometidos
El sitio we-have-a-problem.com, mantenido por el investigador Dennis Jackson, documentó que Apple fue notificado el 17 de octubre de 2026 sobre el compromiso de varios certificados intermedios de eMudhra. Al 28 de octubre, once días después, las herramientas de desarrollo que Apple distribuye con macOS (git, curl y python3) todavía confían en esos certificados.
El 26 de octubre Apple lanzó macOS 27.2. En lugar de eliminar las raíces comprometidas, la actualización deshizo el workaround manual que algunos desarrolladores habían aplicado por su cuenta: quienes habían editado su almacén de certificados para protegerse volvieron a quedar expuestos sin ningún aviso, y tuvieron que repetir el proceso desde cero.
Mientras tanto, decenas de proyectos de código abierto, muchos mantenidos por voluntarios sin presupuesto de seguridad, publicaron sus propios parches días antes de que Apple moviera un dedo. La asimetría es incómoda para una empresa del tamaño de Apple: comunidades pequeñas reaccionaron más rápido que el fabricante del sistema operativo.
Apple fue notificado el 17 de octubre de 2026 y aún no corrige sus herramientas de desarrollo.
Contexto e historia
Las autoridades certificadoras ocupan un lugar incómodo en la arquitectura de confianza de internet: si una sola CA emite un certificado indebido, cualquier cliente que confíe en ella queda expuesto a un atacante capaz de hacerse pasar por cualquier sitio. La industria ya vivió episodios parecidos, como la revocación de confianza en Symantec en 2018 o el colapso de DigiNotar en 2011, y en ambos casos la respuesta coordinada de navegadores y sistemas operativos tomó semanas, no meses.
Lo particular del caso eMudhra es la brecha entre quién corrige rápido y quién no. Apple ya protegió Safari y las apps que usan su framework de red nativo (Network.framework y la Security framework), que manejan la validación de certificados de forma centralizada. El problema queda confinado a las herramientas que no pasan por ahí: las que vienen del mundo Unix y traen su propio stack TLS basado en OpenSSL o LibreSSL.
Apple separó hace años la validación de certificados de Safari y del resto del sistema operativo en nombre de la compatibilidad: muchas herramientas de línea de comandos que trae macOS provienen de proyectos open source empaquetados tal cual, con su propio stack criptográfico. Esa decisión de arquitectura, cómoda durante años, es la misma que hoy deja una brecha abierta entre lo que Apple ya corrigió y lo que todavía no toca.
Detalles técnicos
git, curl y python3 en macOS no verifican certificados contra el almacén de confianza de la Security framework de Apple. En su lugar, usan una copia de OpenSSL o LibreSSL que lee las raíces desde el archivo /etc/ssl/cert.pem. Si una raíz comprometida sigue en ese archivo, cualquier herramienta que dependa de ella validará un certificado fraudulento como legítimo, sin importar que Safari, en la misma máquina, ya lo rechace.
Para comprobar si tu copia de git está afectada, el propio sitio de Jackson ofrece un servidor de prueba:
git ls-remote https://git-emudhra.we-have-a-problem.com/check.git
Un error de certificado significa que tu git está protegido. Si el comando devuelve un commit en lugar de un error, tu copia de git confía en los certificados eMudhra comprometidos y cualquier conexión HTTPS a GitHub u otro remoto puede ser interceptada y alterada en tránsito.
El mismo sitio documenta una prueba de concepto más explícita: redirige temporalmente github.com a un servidor de prueba con la opción http.curloptResolve de git, y ese servidor presenta un certificado de github.com firmado por una de las intermedias comprometidas. Si el clon se completa en lugar de fallar, el README.md resultante empieza con la palabra INTERCEPTED. Un atacante real ni siquiera necesita esa opción: le basta con estar en la ruta de red entre el desarrollador y GitHub, algo trivial en una red wifi compartida, una VPN corporativa mal configurada o un proveedor de tránsito comprometido.
El propio aviso advierte que, al reproducir la prueba de concepto, hay que mantener el prefijo fake-user@ en la URL de clonado: sin él, git enviaría las credenciales reales de GitHub del desarrollador al servidor de prueba, exactamente el mismo mecanismo que usaría un atacante real para robarlas en producción.
python3 hereda el mismo problema porque los módulos ssl y urllib de la distribución de Apple también leen el almacén de /etc/ssl/cert.pem en lugar de consultar la Security framework. Cualquier script que descargue un paquete por HTTPS, desde un pip install hasta un webhook interno, hereda la misma exposición que git y curl.
flowchart TD
A["git, curl o python3 en macOS"] --> B["Conexion HTTPS a github.com"]
B --> C{"Raiz eMudhra comprometida en /etc/ssl/cert.pem?"}
C -->|"Si, confiada"| D["Atacante en la ruta de red"]
D --> E["Presenta certificado falso de github.com"]
E --> F["Clon alterado o credenciales interceptadas"]
C -->|"No, removida"| G["Error de certificado, conexion bloqueada"]
⚠️ Ojo: si tu pipeline de CI usa runners macOS para clonar dependencias o publicar paquetes, cada build corre con la misma copia vulnerable de git hasta que elimines manualmente las raíces comprometidas.
Impacto y análisis
El riesgo no es teórico ni exclusivo de desarrolladores curiosos. Cualquier pipeline de integración continua que use runners macOS para clonar un repositorio privado, descargar una dependencia por HTTPS o publicar un paquete queda expuesto al mismo vector: un atacante con posición de red puede alterar el código que entra a un build o interceptar credenciales como tokens de GitHub, sin que nadie en el equipo lo note.
Mientras los certificados eMudhra comprometidos permanecen activos en macOS, otros proyectos ya resolvieron el problema puertas afuera de Apple: decenas de mantenedores, muchos de ellos voluntarios sin un equipo de seguridad detrás, publicaron sus propios parches días antes de que la actualización 27.2 llegara. Eso invierte la jerarquía habitual, donde se espera que un fabricante del tamaño de Apple reaccione antes que un proyecto comunitario.
Para equipos de seguridad, el caso también es una señal de que confiar ciegamente en el ciclo de parches del sistema operativo no basta: hay que verificar manualmente, repetir la verificación después de cada actualización y documentar el procedimiento como parte del runbook de incidentes, no como un parche de una sola vez.
Qué sigue
Apple ya tiene el camino resuelto para una parte del problema: Safari y las apps construidas sobre su framework de red nativo no confían en las intermedias comprometidas. Lo que falta es extender esa decisión a las herramientas de línea de comandos que distribuye con macOS, algo tan simple en concepto como quitar las raíces afectadas de /etc/ssl/cert.pem en la próxima actualización.
Hasta que eso pase, la guía de mitigación de we-have-a-problem.com describe cómo remover las raíces a mano del almacén de certificados de macOS. El propio aviso de Apple sobre el tema advierte que una actualización del sistema puede revertir ese cambio, así que el procedimiento no es "aplicar una vez": hay que repetir la verificación y, si corresponde, la limpieza manual después de cada actualización de macOS hasta que Apple publique un parche real.
Los equipos de seguridad que dependan de runners macOS en su infraestructura de CI/CD deberían además evaluar el riesgo de cadena de suministro que implica seguir usando esas máquinas para clonar o compilar código mientras el problema no esté resuelto de raíz.
📖 Resumen en Telegram: Ver resumen
Probalo vos: corré hoy mismo git ls-remote https://git-emudhra.we-have-a-problem.com/check.git en tu Mac y confirmá si tu copia de git sigue confiando en los certificados comprometidos.
Preguntas frecuentes
¿Qué herramientas de macOS están afectadas por los certificados eMudhra comprometidos?
Principalmente git, curl y python3, porque usan su propio stack TLS basado en OpenSSL o LibreSSL en lugar del framework de red nativo de Apple.
¿Safari también confía en las intermedias comprometidas de eMudhra?
No. Apple ya protegió Safari y las apps que usan su framework de red nativo; el problema queda limitado a las herramientas de desarrollador que no pasan por ahí.
¿Cómo sé si mi copia de git en macOS sigue siendo vulnerable a eMudhra?
Corriendo git ls-remote https://git-emudhra.we-have-a-problem.com/check.git: un error de certificado significa que estás protegido; si devuelve un commit, tu git sigue confiando en las raíces comprometidas.
¿macOS 27.2 corrigió el problema de eMudhra?
No. La actualización del 26 de octubre de 2026 no eliminó las raíces comprometidas y además revirtió el workaround manual que algunos desarrolladores habían aplicado.
¿Qué puede hacer un desarrollador mientras Apple no publica un parche para eMudhra?
Remover a mano las raíces comprometidas del almacén de certificados de macOS y repetir la verificación después de cada actualización del sistema, ya que una nueva versión puede revertir el cambio.
Referencias
- we-have-a-problem.com: reporte original de Dennis Jackson sobre el estado de Apple frente al compromiso de eMudhra.- Wikipedia: explicación general del rol de las autoridades certificadoras en la cadena de confianza TLS.- curl.se: documentación oficial sobre cómo curl valida certificados TLS y de dónde toma su almacén de raíces.- github.com/git/git: repositorio en GitHub que sirve como mirror de solo publicación del proyecto git, una de las herramientas afectadas.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
Top comments (0)