Certificados eMudhra comprometidos en Git y curl de Apple

En pocas palabras: Sí, siguen confiando en ellos. Apple bloquea los 12 certificados comprometidos de eMudhra desde el 19 de octubre de 2026, pero git, curl y python3 en macOS los aceptan igual porque verifican contra /etc/ssl/cert.pem, un archivo que todavía no se actualizó.

Apple confirmó que bloquea los certificados eMudhra comprometidos desde el 19 de octubre de 2026, pero herramientas de línea de comandos como git, curl y python3 en macOS todavía los aceptan. El motivo es técnico: esas herramientas verifican certificados contra un archivo que Apple no actualizó, /etc/ssl/cert.pem, en vez de usar el bloqueo nativo del sistema.

Los certificados eMudhra comprometidos son doce certificados TLS emitidos por seis autoridades intermedias de eMudhra cuyas claves privadas quedaron expuestas. eMudhra y Sectigo los revocaron, pero algunas herramientas de macOS (git, curl, python3, ruby, perl y openssl) siguen aceptándolos porque validan contra el archivo /etc/ssl/cert.pem en vez de usar el bloqueo nativo del sistema operativo.

¿Qué certificados de eMudhra se comprometieron y cuándo lo confirmó Apple?

Ocho autoridades de certificación intermedias operadas por eMudhra sufrieron el robo de sus claves privadas, según el aviso oficial de Apple publicado el 29 de octubre de 2026. Dos de esas CAs emiten certificados de firma de código (que los frameworks de Apple ya rechazan) y las otras seis emiten certificados TLS, cada una con dos variantes: una que encadena a emSign Root TLS CA – G3 y otra cross-firmada por Sectigo que encadena a AAA Certificate Services. Doce certificados en total, todos con su fingerprint SHA-256 publicado por Apple.

La cronología importa. Apple empezó a bloquear esos doce certificados el 19 de octubre de 2026 y, cuatro días después, el 23 de octubre, sumó el bloqueo del root emSign ECC Root CA – G3. El caso quedó registrado también en el bug 2083449 de Bugzilla, abierto por Dennis Jackson, con seguimiento en Firefox ESR 115 y ESR 153, y en Firefox 159, 160 y 161. eMudhra y Sectigo revocaron las certificaciones afectadas, pero la revocación en el ecosistema web no implica que cada herramienta instalada en tu Mac la respete de inmediato.

¿Por qué git, curl y python3 de macOS no quedaron protegidos automáticamente?

Porque esas herramientas no pasan por el framework de seguridad de Apple: verifican las cadenas de certificados contra el archivo /etc/ssl/cert.pem, tal como aclara el propio soporte de Apple. El bloqueo que llega vía Safari, Mail y las apps que usan las APIs nativas de red no toca ese archivo. Para git, curl, python3, ruby, perl y openssl, el certificado comprometido sigue pareciendo perfectamente válido.

¿Y el parche que salió esta semana lo arregló? Según el reporte de RuntimeWire basado en un hilo de Hacker News, la actualización macOS 27.2 del 26 de octubre de 2026 no tocó este punto. El tema es que Apple ya avisó que la corrección definitiva de /etc/ssl/cert.pem llega en una futura actualización de software, sin fecha confirmada todavía.

¿Qué riesgo real corren los pipelines de CI/CD que usan runners macOS?

El riesgo confirmado es sobre el transporte HTTPS, no sobre la firma de commits. Si tu runner macOS clona o hace pull de un repositorio por HTTPS, alguien con acceso a las claves comprometidas de eMudhra podría intentar un ataque man-in-the-middle contra esa conexión sin que git se queje, porque la cadena de certificados todavía valida contra el archivo viejo. Ya lo cubrimos antes en casos previos de pipelines comprometidos en GitHub Actions.

En la práctica, eso abre tres frentes concretos para equipos de AI infra o DevOps que mezclan workstations macOS con pipelines de CI/CD: robo de tokens de GitHub o GitLab en tránsito, inyección de dependencias en un clone que parece legítimo, y descarga de artefactos de build (imágenes Docker, paquetes de modelos) desde un origen suplantado. Ponele que tenés un runner macOS en la nube que clona un repo privado por HTTPS cada vez que corre un job: ese paso queda expuesto mientras la herramienta siga confiando en el certificado revocado.

Componente macOS	¿Usa el bloqueo nativo de Apple?	¿Protegido automáticamente?
Safari, Mail, apps con frameworks nativos	Sí	Sí, desde el 19/10/2026
git (bundled con Xcode CLT)	No, usa /etc/ssl/cert.pem	No hasta el próximo update
curl	No, usa /etc/ssl/cert.pem	No hasta el próximo update
python3, ruby, perl, openssl	No, usa /etc/ssl/cert.pem	No hasta el próximo update

¿Qué límites tiene esta falla (y qué no soluciona)?

El artículo original de dev.to ubica el compromiso “back in 2022”, pero eso no coincide con la cronología oficial: el aviso de Apple y el bug de Mozilla sitúan el descubrimiento y el bloqueo en octubre de 2026. Tomá ese detalle con pinzas si leés la fuente derivada, porque mezcla fechas.

Ahora bien, hay otro punto flojo en esa misma nota: el chequeo que propone (git verify-commit HEAD | grep -i "eMudhra") parte de la idea de que la firma de commits usa estos certificados de CA TLS, y no es así. La firma de commits en git funciona con claves GPG o SSH, un mecanismo separado de la cadena de confianza TLS que valida eMudhra. Lo que está roto acá es la verificación de certificados de servidor al hacer HTTPS, no la verificación de autoría de un commit. Mezclar ambas cosas lleva a mitigaciones que no atacan el problema real.

¿Cómo mitigar el riesgo mientras Apple no actualiza el trust store?

Apple publicó comandos oficiales para remover manualmente las CAs comprometidas de /etc/ssl/cert.pem, sin esperar al próximo update de macOS. Es la vía recomendada por la propia empresa, no un workaround de terceros.

• Hacé un backup del archivo antes de tocar nada. El comando oficial de Apple crea /etc/ssl/cert.pem.orig solo si no existe ya, así que podés correrlo una vez por máquina sin pisar un backup previo.
• Remové emSign ECC Root CA – G3 con el script de Apple. Genera una copia del archivo sin esa entrada, valida que no quede vacía y la instala con permisos root:wheel.
• Evaluá si también removés AAA Certificate Services. Las seis certificaciones cross-firmadas por Sectigo siguen validando a través de esa CA si no la sacás también, así que Apple lo deja como paso opcional pero recomendado.
• Verificá con openssl que ambas entradas desaparecieron. El comando de chequeo que da Apple no muestra nada si el proceso salió bien; si aparece una CA, restaurá el backup y repetí.
• Repetí el proceso después de cada actualización de macOS hasta que instales la que efectivamente reemplace /etc/ssl/cert.pem con la versión corregida de Apple.

Si corrés tus propios runners de CI/CD fuera del ecosistema de Apple, por ejemplo en VPS Linux bajo tu control, el problema ni te toca porque esas distros no dependen de este archivo específico de macOS. Para infraestructura de hosting y VPS en Argentina, donweb.com es una opción donde manejás vos mismo qué certificados confía el sistema, sin depender del calendario de parches de Apple.

Qué está confirmado y qué no

Confirmado por Apple: el compromiso de ocho CAs intermedias de eMudhra, los doce certificados bloqueados, las fechas 19 y 23 de octubre de 2026, y que git, curl, python3, ruby, perl y openssl siguen validando contra /etc/ssl/cert.pem hasta un update futuro.

No confirmado, o directamente impreciso en la cobertura derivada: la fecha de 2022 que menciona dev.to, y la idea de que esto afecta la firma GPG de commits. Tampoco hay fecha publicada para el update de macOS que reemplace el archivo de forma definitiva. Tema relacionado: soporte de Linux en MacBook Pro con chip T1 (modelos Intel, sin soporte para Apple Silicon).

Errores comunes al reaccionar a esta falla

• Pensar que macOS 27.2 ya resolvió el problema. Según RuntimeWire, el update del 26 de octubre no tocó /etc/ssl/cert.pem; seguís expuesto si no editás el archivo a mano.
• Confundir esto con un problema de firma de commits. La verificación GPG o SSH de autoría no usa estas CAs de TLS; son dos capas de confianza distintas.
• Borrar todo /etc/ssl/cert.pem en vez de solo las dos CAs afectadas. Eso rompe la verificación de cualquier sitio cuyo certificado encadene a otras raíces legítimas que viven en el mismo archivo.
• No volver a correr el chequeo después de cada update de macOS. Apple aclara que una actualización puede reemplazar el archivo (sin el fix completo) y tu edición manual se pierde sin que te enteres.

Preguntas Frecuentes

¿Qué pasó con los certificados de eMudhra?

Ocho autoridades de certificación intermedias operadas por eMudhra sufrieron el robo de sus claves privadas. eMudhra y Sectigo revocaron los certificados afectados, y Apple empezó a bloquearlos en sus dispositivos desde el 19 de octubre de 2026.

¿Por qué Apple no bloqueó eMudhra en git y curl de macOS?

Porque git y curl verifican certificados contra el archivo /etc/ssl/cert.pem en vez de usar el framework de seguridad nativo de Apple. El bloqueo automático solo llega a Safari, Mail y apps que usan las APIs del sistema; la corrección para herramientas de línea de comandos queda pendiente de un futuro update de macOS.

¿Mi pipeline de CI/CD está en riesgo por los certificados eMudhra?

Sí, si usás runners macOS que clonan repos o descargan paquetes por HTTPS con git, curl o python3 sin editar manualmente /etc/ssl/cert.pem. El riesgo es sobre el tráfico TLS, no sobre la firma de commits GPG.

¿Cómo saco los certificados eMudhra de mi Mac?

Apple publicó comandos oficiales para hacer un backup de /etc/ssl/cert.pem y remover ahí mismo emSign ECC Root CA – G3 y, opcionalmente, AAA Certificate Services. Después de correrlos, verificás el resultado con openssl antes de cerrar la terminal.

¿Qué herramientas de macOS siguen confiando en eMudhra?

Git, curl, python3, ruby, perl y openssl, según el soporte oficial de Apple, porque todas chequean contra /etc/ssl/cert.pem en lugar del bloqueo nativo del sistema.

Conclusión

Lo que cambió es simple de resumir: Apple bloqueó doce certificados eMudhra comprometidos a nivel sistema, pero dejó afuera a las herramientas de línea de comandos que usan desarrolladores y pipelines de CI/CD todos los días. Si tu equipo corre builds en macOS y clona repos por HTTPS, el paso que tenés que dar hoy es editar /etc/ssl/cert.pem con los comandos oficiales de Apple, no esperar al próximo update sin fecha. Y si vas a revisar guías de terceros sobre el tema, chequeá bien las fechas y no mezcles verificación TLS con firma de commits: son cosas distintas, y confundirlas te hace perder tiempo arreglando lo que no estaba roto.

Fuentes

• Apple Support – About the compromised eMudhra intermediate CAs
• Bugzilla Mozilla – eMudhra: Private key compromise of Intermediate Certificates (bug 2083449)
• RuntimeWire – Apple leaves macOS command-line tools trusting compromised eMudhra certificates
• Dev.to – Apple’s Git Still Trusts Compromised eMudhra Certificates