eMudhra, 11 days after the disclosure: macOS's bundled git and curl still trust the compromised certificates, per Apple's own support note
Apple's support note confirms macOS-bundled git, curl and python3 don't check revocation and still trust the compromised eMudhra roots. git clone is MITM-able.
Apple’s support note, “About the compromised eMudhra intermediate CAs” (page dated October 29), says some command-line tools included with macOS, such as git and curl, check certificates against /etc/ssl/cert.pem and may still accept affected certificates until a future software update. Apple says administrators can remove the affected root certificates manually.
Key points
- Apple explains the command-line limitation. Support note 149555 says some tools included with macOS or the Xcode Command Line Tools, such as
curlandgit, check/etc/ssl/cert.pemand may still accept affected certificates until a future software update. Apple’s automatic blocking covers Safari, Mail and apps using Apple networking and security frameworks. - One command tests your git. The disclosure site’s check is
git ls-remote https://git-emudhra.we-have-a-problem.com/check.git— a certificate error means you’re protected; a listed commit means your git still trusts the compromised chain. - Microsoft shipped an out-of-band fix; Apple promised a future one. Per BleepingComputer, Microsoft released KB5134133 / KB5134125 on October 26 to pull seven related certificates out of the Windows trust list. macOS 27.2 shipped the same day and, per the researchers, neither fixed the issue nor preserved manual cleanup.
Background
We covered this incident in full on October 21: eMudhra, a Bengaluru-based certificate authority, issued eight intermediate CA certificates whose private keys carry just 8 bits of entropy. Researcher Scott Helme recovered all eight keys from public certificates on a laptop in under a second. Our October 23 digest also recorded eMudhra’s decision to exit the global SSL/TLS business. Apple’s support note 149555, dated October 29, explains that some command-line tools may still accept affected certificates.
Discussion kept moving after the note. On October 28 the disclosure site put up a dedicated page, “Apple’s git still trusts the compromised eMudhra certificates,” which made the front page of Hacker News the same day with over 1,100 points. The page adds two claims: the developer tools remain unfixed, and macOS 27.2 reverts the cleanup users had applied by hand while still shipping the compromised certs.
The facts
Dates from all the sources, lined up (2026; UTC per each source’s own account):
| Date | Event | Source |
|---|---|---|
| Oct 17 | Report reaches the four root programs; Firefox and Chrome block the same day | Disclosure site |
| Oct 19 | Apple starts blocking the 12 compromised intermediates (Apple’s own account) | Support note 149555 |
| Oct 20 | Microsoft platforms block; non-browser trust stores begin to follow | Disclosure site |
| Oct 22 | Apple platform blocking complete (disclosure site’s account, differing from the official 19th) | Disclosure site |
| Oct 23 | Apple publishes support note 149555; starts blocking the emSign ECC Root CA - G3 root | Support note 149555 |
| Oct 26 | Microsoft ships out-of-band KB5134133 / KB5134125; macOS 27.2 released the same day | BleepingComputer, disclosure site |
| Oct 28 | Disclosure site update: developer tools still unfixed, 27.2 reverts manual cleanup | Disclosure site apple.html |
Apple’s note confirms three things in its own words. First, the bundled tools — curl, git, python3, ruby, perl, openssl — validate against /etc/ssl/cert.pem, and for chains rooted there they “don’t check Apple’s block or whether the certificate has been revoked.” Second, the fix path: “a future macOS update” will refresh the file automatically, and until then users may remove the roots by hand. Third, the note spells out backup, removal of emSign ECC Root CA - G3 (optionally along with Sectigo’s AAA Certificate Services) and verification commands — while warning that a macOS update may rewrite the file, bring the roots back, and force you to redo the cleanup after every update.
The disclosure page puts the consequence in terms developers live with: anyone on the network path can intercept any HTTPS connection these tools make. For git, that means clones and pulls from https:// remotes can deliver attacker-chosen code, pushes can be altered in transit, and credentials such as GitHub tokens can be intercepted. The page demonstrates a full attack with a test server impersonating github.com, presenting a certificate issued by one of the compromised intermediates; a real attacker wouldn’t need the demo’s -c redirect flag, because they can reroute your traffic themselves.
Two account conflicts are worth stating plainly. One: the blocking start date. Apple’s note says October 19 for the 12 intermediates; the disclosure site’s timeline says October 22 — likely “started” versus “completed,” and it does not change the core accusation. Two: macOS 27.2. Apple’s note predates 27.2’s release, so it naturally says nothing about it; the claim that 27.2 neither fixed the issue nor preserved manual cleanup rests on a single source, the researchers, and has no second independent confirmation or Apple response yet.
What others say
Microsoft’s move provides a comparison with Apple’s guidance to wait for a future software update. BleepingComputer reported on October 27 that Microsoft shipped out-of-band updates on October 26 — KB5134133 for Windows 11 24H2/25H2/26H2 and KB5134125 for Windows 10 21H2/22H2 — removing six eMudhra G3 roots and one AAA Certificate Services cross-sign from the Windows trust list, mainly for offline machines and devices with automatic certificate updates disabled. Microsoft noted that pulling a root from a trust list is not the same as revoking the known compromised intermediates — a broader, separate trust decision — and said it is still investigating eMudhra’s remaining roots.
Helme’s October 20 analysis explains why “the certificates are revoked” doesn’t help here: most non-browser clients — curl, Python, Node, Go, Java, package managers, CI scripts — trust a CA bundle on disk, don’t check revocation by default and ignore Certificate Transparency, so revocation is on paper only for them. On every macOS machine he tested, curl, Python and Node accepted the forged certificate with default settings. His arithmetic: the certificates were minted in April 2025, so 8 bits of entropy guarded that software for 17 months.
The Hacker News thread adds ground-level detail. One commenter ran the check and got a commit listed — with which git pointing at /opt/homebrew/bin/git: the affected git was Homebrew’s. Homebrew maintainer woodruffw first said its curl was unaffected because Homebrew ships its own CA bundle, then owned the gap: “I spoke too soon about Git being patched just because our own CA bundle was,” and a fix PR (homebrew-core #321878) followed. Several commenters tested curl separately: one got a successful connection through /usr/bin/curl (“That’s bad!”), and another found his brew-installed curl failing with error 60 while the /usr/bin one connected fine. Others reminded readers who had cleaned up by hand that the check has to be rerun after every software update, because updates rewrite /etc/ssl/cert.pem.
Our take
The lasting lesson here isn’t that Apple was slow — it’s the boundary Apple’s own note draws. /etc/ssl/cert.pem updates on the macOS release cadence, and revocation never covers it. The next time a root is compromised, the bundled CLI tools will lag by an update cycle again. Homebrew shows that distribution channels trip the same way — its own maintainer admitted git hadn’t followed the CA bundle. What developers can actually do is check where each tool’s trust comes from: /usr/bin/git, Homebrew’s git, system python3 and a pyenv-installed python3 on the same machine may not share a CA file, and a passing browser test says nothing about your build machine. The disclosure site also asks security teams to check whether CI runs on macOS runners — build-infrastructure supply-chain risk is the same risk as on a laptop, just with more reach.
Two things remain open. The macOS 27.2 behavior is a single-source claim that the next macOS update will test on its own. And there is no date for when Apple actually removes the compromised roots from /etc/ssl/cert.pem. In our October 21 piece we noted that volunteer-run projects — Go, certifi, webpki-roots — had fixes out within days. Against that, the company that owns the entire operating-system update pipeline has offered an undated promise, which may be the hardest part of this story to accept.
How to try it
Test git first, one command:
git ls-remote https://git-emudhra.we-have-a-problem.com/check.git
A certificate error means your git is protected; a listed commit means it still trusts the compromised chain. Then curl:
curl https://dv-g3b-noct-emudhra.we-have-a-problem.com/
curl https://dv-g3b-aaa-noct-emudhra.we-have-a-problem.com/
To clean up, follow Apple’s support note 149555: only if the backup does not already exist, run [ -e /etc/ssl/cert.pem.orig ] || sudo cp -p /etc/ssl/cert.pem /etc/ssl/cert.pem.orig so you do not overwrite an existing backup. Then remove emSign ECC Root CA - G3 (optionally with AAA Certificate Services) using the note’s awk commands, and verify with its openssl command. Apple warns that a software update may restore the file. Keep the fake-user@ prefix when running the disclosure site’s demo commands so your real credentials do not go to its test server.