Las herramientas de desarrollo de Apple macOS siguen confiando en los certificados comprometidos de eMudhra

Apple no ha logrado parchear un problema crítico de confianza en certificados dentro de sus herramientas de desarrollo a finales de octubre de 2026. A pesar de haber sido notificada sobre la vulneración el 17 de octubre, la última actualización del sistema operativo de la compañía, macOS 27.2, lanzada el 26 de octubre, no resolvió la vulnerabilidad e incluso revirtió las correcciones manuales aplicadas por los usuarios. Esto deja expuestos a posibles ataques de intermediario (man-in-the-middle) a los desarrolladores que utilizan herramientas estándar de línea de comandos como git, curl y python3.

Qué ocurrió

El problema central involucra certificados digitales emitidos por eMudhra, una autoridad de certificación que sufrió una vulneración de seguridad. Cuando una autoridad de certificación es comprometida, los atacantes pueden crear certificados falsos para cualquier sitio web, incluidas plataformas importantes de alojamiento de código como GitHub. Estos certificados falsos permiten a los atacantes interceptar tráfico cifrado sin activar las advertencias de seguridad estándar. Si bien Apple actualizó rápidamente Safari y otras aplicaciones construidas sobre sus frameworks nativos de red para dejar de confiar en estos certificados específicos, descuidó las herramientas de desarrollo independientes incluidas con el sistema operativo.

En consecuencia, herramientas como git, curl y python3 continúan confiando en los certificados raíz comprometidos de eMudhra. Esto crea un riesgo significativo para los flujos de trabajo de desarrollo de software. Cuando un desarrollador clona un repositorio o envía código utilizando HTTPS, sus herramientas dependen de estos certificados para verificar la identidad del servidor remoto. Si los certificados son considerados confiables a pesar de estar comprometidos, un atacante posicionado en la ruta de red puede suplantar a GitHub u otros servicios. Esto les permite servir código malicioso durante una operación de clonado o robar credenciales, como tokens de acceso personal, durante la autenticación.

La situación se agravó con el lanzamiento de macOS 27.2. Muchos desarrolladores conscientes de la seguridad habían eliminado manualmente los certificados comprometidos de sus almacenes de confianza del sistema para protegerse. Sin embargo, esta actualización del sistema operativo restableció el almacén de certificados, deshaciendo efectivamente la solución manual y dejando a estos usuarios nuevamente vulnerables. En contraste, muchos otros proyectos de código abierto y distribuciones mantenidas por voluntarios publicaron correcciones en cuestión de días desde la notificación inicial, destacando una disparidad en los tiempos de respuesta entre los esfuerzos impulsados por la comunidad y la gestión de Apple de su cadena de herramientas de desarrollo.

Detalles clave

• Apple fue notificada oficialmente sobre la vulneración de los certificados de eMudhra el 17 de octubre de 2026.
• Al 28 de octubre de 2026, las herramientas de desarrollo de macOS, incluyendo git, curl y python3, aún confían en los certificados comprometidos.
• La actualización de macOS 27.2, lanzada el 26 de octubre de 2026, no corrigió el problema y revirtió las soluciones manuales de los usuarios.
• Los atacantes pueden interceptar conexiones HTTPS, alterando potencialmente el código durante los clones de git o robando credenciales.
• Safari y las aplicaciones que usan el framework de red nativo de Apple están protegidas, pero las herramientas de línea de comandos no lo están.
• Los usuarios deben volver a aplicar las correcciones manuales después de cada actualización de macOS hasta que se lance un parche oficial.

Contexto

Para entender la gravedad de este problema, ayuda saber cómo funcionan las conexiones web seguras. Cuando te conectas a un sitio web mediante HTTPS, tu computadora verifica el certificado digital del sitio para asegurarse de que sea legítimo. Este certificado está firmado por una Autoridad de Certificación (CA), un tercero de confianza. Tu sistema operativo mantiene una lista de CAs confiables. Si una CA es comprometida, como ocurrió con eMudhra, los atacantes pueden emitir certificados con apariencia válida para dominios que no poseen. Esto rompe la cadena de confianza, permitiéndoles descifrar y modificar tráfico que parece seguro para el usuario.

Las herramientas de desarrollo como git y curl dependen del almacén de certificados del sistema para verificar las conexiones a los repositorios de código. A diferencia de los navegadores web, que a menudo tienen sus propios almacenes de certificados o mecanismos de actualización, estas herramientas de línea de comandos suelen utilizar el almacén de confianza subyacente del sistema operativo. En macOS, esto significa que consultan la misma lista de raíces confiables que utiliza el sistema. Si Apple elimina un certificado malo de Safari pero lo deja en el almacén del sistema usado por git, los desarrolladores permanecen en riesgo. Esta distinción entre las protecciones a nivel de navegador y las herramientas a nivel de sistema es crucial para entender por qué algunas aplicaciones son seguras mientras que otras no lo son.

Por qué importa

Para los equipos que ejecutan su propio software o gestionan infraestructura interna, esta vulnerabilidad representa una amenaza directa a la cadena de suministro. Si un desarrollador clona un repositorio mientras está en una red no confiable, como Wi-Fi público o una red corporativa comprometida, un atacante podría inyectar código malicioso en el proyecto. Este código podría parecer legítimo pero contener puertas traseras, mineros de criptomonedas o scripts de exfiltración de datos. Dado que el ataque ocurre durante el proceso de descarga, las revisiones de código estándar podrían pasar por alto la inyección si el atacante modifica el código antes de que llegue a la máquina del desarrollador.

Además, la intercepción de credenciales plantea un riesgo severo para la seguridad de las cuentas. Los tokens de GitHub y otras claves API enviadas sobre HTTPS suelen estar a salvo de escuchas. Sin embargo, con un certificado confiable pero comprometido, un atacante puede descifrar este tráfico en tiempo real. Esto les permite robar tokens de autenticación, que luego pueden usarse para acceder a repositorios privados, modificar entornos de producción o escalar privilegios dentro de una organización. Para los ingenieros de DevOps que gestionan pipelines CI/CD, este riesgo se extiende a los runners automatizados que también pueden estar usando versiones afectadas de macOS.

La reversión de las correcciones manuales por parte de las actualizaciones de macOS añade una carga operativa a los equipos de seguridad. No basta con aplicar una corrección una sola vez; los equipos ahora deben verificar la integridad de sus almacenes de certificados después de cada actualización del sistema operativo. Esto aumenta la probabilidad de error humano, donde un desarrollador asume que está protegido porque aplicó una corrección previamente, solo para quedar expuesto nuevamente por una actualización silenciosa del sistema. Esta incertidumbre socava la confianza en la postura de seguridad de la plataforma y requiere una vigilancia constante.

Qué puedes hacer

• Prueba tu instalación de git ejecutando el comando de verificación proporcionado por los investigadores de seguridad para comprobar si rechaza el certificado comprometido.
• Prueba tu instalación de curl intentando conectar a los dominios de prueba alojados por la comunidad de seguridad para confirmar la protección.
• Elimina manualmente los certificados raíz comprometidos de eMudhra de tu llavero del sistema macOS si aún están presentes.
• Vuelve a verificar tu almacén de confianza de certificados después de cada actualización de macOS, ya que las actualizaciones del sistema pueden restaurar los certificados comprometidos.
• Evita clonar repositorios o enviar código sobre HTTPS en redes no confiables hasta que Apple lance una corrección oficial.
• Considera usar SSH para operaciones de git en lugar de HTTPS, ya que SSH utiliza un modelo de confianza diferente que no se ve afectado por este problema de certificados.