If you code on a Mac, your git may still swallow a fake GitHub certificate. On October 28, the community site tracking the eMudhra disaster published that the developer tools Apple ships with macOS (git, curl and python3, among others) were still trusting the compromised intermediate certificates, and that macOS 27.2, released on October 26, did not fix it and even undid the manual patch many people had already applied. Apple confirmed it in its own guide on October 29: those tools will keep accepting the certificates "until a future software update."
The root problem: keys anyone can extract
The private keys of eight intermediate certificates from the Indian certificate authority eMudhra were generated so badly that they can be recovered from the public certificates. Cloudflare summed it up with a brutal image: where eMudhra was supposed to pick a 115-digit number, it picked 4. The other seven keys were just as weak: 56, 66, 115, 155, 156, 230 and 237.
Six of those intermediates issue TLS certificates. With them, anyone can forge a certificate that looks valid for any site. According to Apple, each one has two certificates (12 in total): one that chains to the emSign ECC Root CA - G3 root and another cross-signed by Sectigo that chains to AAA Certificate Services. eMudhra and Sectigo have already revoked them, and Ars Technica reports that eMudhra announced it is leaving the public certificate business.
Browsers protected themselves quickly: Firefox and Chrome have blocked them since October 17, according to the tracking site. Apple says it started blocking all 12 certificates on October 19 and the emSign ECC Root CA - G3 root on the 23rd. But that block only protects Safari, Mail and apps that use Apple's network frameworks.
Why the terminal got left out
Here is the detail that matters to any developer. According to Apple, curl, git, python3, ruby, perl and openssl, included in macOS or in the Xcode Command Line Tools, validate against the /etc/ssl/cert.pem file. And for certificates that chain to a root in that file, "they don't check Apple's blocklist or whether the certificate was revoked."
In practice, according to the tracking site, anyone on the network path between your Mac and GitHub can serve you code of their choosing in a clone or a pull over https://, tamper with a push, and steal credentials such as GitHub tokens. And since curl and many non-browser clients don't require Certificate Transparency, an attack like this can go by without anyone seeing it.
Are there attacks already?
On October 30, Cloudflare published what it has seen on its network. It counted about 22,000 connection attempts with certificates signed by the weak keys. Most were tests, but about 160 carried forged certificates with other organizations' domains, one dated October 20 at 18:19 UTC, less than an hour after the report was made public on Mozilla's bugzilla. Cloudflare clarifies that it found no evidence they were used to intercept its connections, although that doesn't rule out targeted attacks.
The most worrying part is the patching on the user side. With 50 million probes from its challenge pages, Cloudflare sees that modern browsers are already patched, but bots, old browsers and embedded ones are not: between 30% and 40% of Android WebView still accepts the compromised chain. On large networks, more than half of the probes still accept it. Cloudflare warns that this traffic is skewed by bots.
What to do if you use a Mac
I haven't tested this; it comes from Apple's official guide and the tracking site. First, check whether your git is affected:
git ls-remote https://git-emudhra.we-have-a-problem.com/check.git
If it gives you a certificate error, you're protected. If it lists a commit, you're exposed. For curl, the site suggests curl https://dv-g3b-noct-emudhra.we-have-a-problem.com/.
If you're exposed, Apple documents how to remove the roots from /etc/ssl/cert.pem: back up the file, remove emSign ECC Root CA - G3 and, optionally, also AAA Certificate Services, because otherwise the six Sectigo cross-signed certificates still get through. The cost: some legitimate sites that chain to those roots may fail in those tools. Heads up: Apple warns that every macOS update can replace the file, so you have to repeat the check after each update until its fix arrives.
And if your company uses macOS runners in CI, the tracking site recommends assessing the supply chain risk. A build that clones dependencies over HTTPS on an unpatched Mac is exactly the ugly scenario.
My take
What's uncomfortable isn't that it happened, but the contrast. Dozens of projects, many of them run by volunteers, published patches within days: Debian, Alpine, Arch, Fedora, FreeBSD and Homebrew appear on the list. Apple, with the Safari block sorted since October 19, shipped a system update that put its developers back at square one. Cloudflare puts it well: a trust store can't be a static list of roots; it needs to be able to update quickly with revocations. In the meantime, you have to keep an eye on your Mac's terminal yourself.
Sources
- Apple: About the compromised eMudhra intermediate CAs
- Apple's git still trusts the compromised eMudhra certificates (we-have-a-problem.com)
- eMudhra Intermediate CA Compromise: community tracking
- Cloudflare: 4 real? Tracking exploitation and patching of eMudhra's weak keys
- Cloudflare: initial response to the eMudhra compromise
- Ars Technica: eMudhra exits the TLS business