Reporte: macOS 27.2 revierte el parche manual contra eMudhra

Lo esencial

• macOS 27.2, lanzado el 26 de octubre de 2026, revirtió el workaround manual contra eMudhra.
• Apple fue notificada del incidente el 17 de octubre y once días después sigue sin parchar git, curl y python3.
• git, curl y python3 de macOS siguen confiando en los certificados comprometidos de eMudhra.
• Docenas de proyectos open source ya corrigieron el problema; Apple protegió Safari pero no sus herramientas de desarrollo.
• Un comando de ls-remote permite comprobar en segundos si tu git está expuesto a la intercepción.

Qué pasó

Apple recibió el aviso sobre los certificados comprometidos de eMudhra, la autoridad certificadora india, el 17 de octubre de 2026. Once días después, según el reporte publicado por Dennis Jackson, las herramientas de desarrollo que vienen con macOS (git, curl y python3 entre ellas) todavía confían en esos certificados.

El problema no es nuevo para el resto del ecosistema. Decenas de proyectos, muchos mantenidos por voluntarios sin presupuesto, ya aplicaron su propio arreglo días antes de que Apple moviera un dedo.

El cronograma del fallo

macOS 27.2 salió el 26 de octubre de 2026. En lugar de corregir el problema de raíz, la actualización deshizo el workaround manual que algunos desarrolladores ya habían aplicado, devolviéndolos al estado vulnerable sin avisarles.

Apple sí protegió Safari y las apps que usan su framework de red propio. Pero las herramientas de línea de comandos, que corren fuera de ese framework, quedaron fuera del parche.

Por qué importa para los desarrolladores

Cualquiera que esté en la ruta de red entre tu máquina y un servidor remoto puede interceptar una conexión HTTPS que use estos certificados. En git eso significa que un clone o pull puede entregar código elegido por el atacante en lugar del real.

Un push también puede alterarse en tránsito, y las credenciales que viajan en la conexión (como un token personal de GitHub) pueden quedar expuestas. No hace falta acceso físico a tu red local: basta estar en cualquier punto intermedio del tráfico.

Cómo comprobar si tu git está expuesto

El reporte incluye un servidor de prueba para verificarlo sin riesgo. Corré este comando:

git ls-remote https://git-emudhra.we-have-a-problem.com/check.git

Si tu git devuelve un error de certificado, estás protegido. Si en cambio lista un commit, tu git confía en los certificados comprometidos y cualquier conexión a GitHub u otro remoto por HTTPS puede ser interceptada.

Para ver el ataque completo, podés simular un GitHub falso en un directorio temporal:

git -c http.curloptResolve=github.com:443:15.235.19.186 clone https://fake-user@github.com/galadran/emudhra-git-test

Un git parchado rechaza la conexión con un error de certificado. Si el clone funciona, el README.md descargado empieza con la palabra INTERCEPTED. El prefijo fake-user@ es obligatorio en la prueba: sin él, git enviaría tus credenciales reales de GitHub al servidor de prueba.

Verificar curl y otras herramientas

curl, python3 y el resto de utilidades que Apple distribuye con macOS comparten el mismo almacén de certificados y están afectadas igual que git. Para revisar curl, corré:

curl https://dv-g3b-noct-emudhra.we-have-a-problem.com/
curl https://dv-g3b-aaa-noct-emudhra.we-have-a-problem.com/

Un error de certificado en ambas peticiones confirma que curl está protegido. Si alguna responde sin error, curl todavía confía en los certificados comprometidos.

Qué puede hacer un desarrollador mientras tanto

La guía del propio reporte explica cómo eliminar a mano los certificados afectados del archivo de confianza del sistema. Apple avisa que sus actualizaciones pueden revertir ese arreglo manual, así que hay que repetir la comprobación y el workaround después de cada actualización de macOS hasta que llegue un parche real.

Los equipos de seguridad que usan runners de macOS en su CI o en cualquier infraestructura de build deberían evaluar si ese riesgo de cadena de suministro aplica a sus pipelines.

Qué sigue

Apple ya tiene el camino técnico disponible: quitar las raíces comprometidas de /etc/ssl/cert.pem, el mismo tipo de corrección que aplicaron los demás proyectos afectados. Lo que falta es que lo empaquete en una actualización para desarrolladores, algo que no ocurrió ni en macOS 27.2 ni en los once días posteriores al aviso inicial.

Conclusión

El caso deja un patrón incómodo: Apple protegió primero lo que afecta a usuarios finales (Safari) y dejó para después lo que afecta a desarrolladores (git, curl, python3), aun sabiendo que una actualización intermedia podía borrar el parche que la propia comunidad había improvisado. Mientras no llegue una corrección oficial, la única defensa real es repetir la comprobación manual después de cada actualización de macOS.

📖 Versión extendida con más detalle: https://elsolitario.org/2026/10/28/macos-27-2-revierte-el-parche-manual-contra-emudhra-segun/?utm_source=telegraph&utm_medium=instant_view&utm_campaign=programacion