Apple's git and curl Still Trust the Eight eMudhra Certificates, 11 Days After the Report

An attacker who sits on the network path between a Mac and a git host can present a forged certificate that git, curl and python3 on macOS will accept, provided the forgery chains to one of eight eMudhra intermediate certificate authorities whose private keys are public knowledge. Dennis Jackson, a cryptography engineer at Mozilla, wrote on October 28 that Apple's command-line tools still trust those chains, and that macOS 27.2, released October 26, "did not fix the issue and undid the workaround that users had applied by hand."

The mitigation is to remove two roots from /etc/ssl/cert.pem by hand and repeat that after every macOS update. Apple has not shipped a fix for the command-line tools.

Timeline from October 17 to October 28

The keys were reported to the browser root programs on October 17 by a researcher credited by Mozilla only as "Wayne". Chrome had a block in place by 19:45 UTC that day and Firefox finished its block at 22:59 UTC, according to The Hacker News. The keys were generated with too little randomness, so they can be computed from the public certificates. Scott Helme, a security researcher, said he recovered all eight in under a second.

Apple began blocking 12 certificates on October 19 and added emSign ECC Root CA - G3 on October 23, Apple's support note states. Jackson's page says Apple was told on October 17. Our earlier report on the weak keys covers how the flaw arose.

Why Safari is protected and git is not

Apple's note says Safari, Mail and apps built on Apple's networking and security frameworks block the certificates automatically. Tools that check /etc/ssl/cert.pem do not. The note lists curl, git, python3, ruby, perl and openssl as still affected, and says apps that bundle their own root lists are not covered either.

The score here is not a CVSS number, because neither Apple nor Jackson cites a CVE for the command-line tools. The preconditions matter more. The attacker needs a position on the network path, and a certificate for the target hostname signed with one of the compromised keys. Jackson's page says anyone can intercept HTTPS from these tools, and describes cloned repositories carrying attacker-chosen code and intercepted GitHub tokens as the consequence.

What eMudhra and the root programs have said

eMudhra said none of the eight intermediates issued end-entity certificates and only one was deployed in production. Google found no certificate chaining to the six TLS intermediates in Certificate Transparency logs before Chrome's block. India's CERT-In advisory CIAD-2026-0050, dated October 21, said the disclosures did not confirm malicious use as of that date. No source I fetched reports a forged certificate used against a real target.

Platform or tool	Block shipped	Source
Chrome	October 17	The Hacker News
Firefox	October 17	The Hacker News
Safari, Mail (Apple frameworks)	October 19	Apple support
Microsoft platforms	October 20	The Hacker News
Go 1.27.3 and 1.26.10	October 20	The Hacker News
git, curl, python3 on macOS	Not shipped as of October 28	Jackson

What to do on a Mac today

Apple's note says most users need no action, and offers an optional step for administrators: back up /etc/ssl/cert.pem, remove the emSign ECC Root CA - G3 root, and remove AAA Certificate Services to stop the Sectigo cross-signed copies. Removing them may break verification for some sites that use other intermediates, and an update can restore the file.

Jackson's page offers a test: git ls-remote https://git-emudhra.we-have-a-problem.com/check.git should return a certificate error on a protected machine. Teams running macOS CI runners should run it on each image (our report on Node.js's October security release covers the same eMudhra distrust in another runtime), since a runner that clones over HTTPS with a token is the case where interception costs the most.

The next milestone is a macOS update that changes the command-line trust store. Apple's note gives no version or date.