eMudhra CA Compromise on macOS: Why git and curl Still Trust the Leaked Keys
By Arash Latifi
Practical guide to testing your git/curl/python against the compromised eMudhra intermediates, verifying with the researcher's test domains, and manually fixing macOS trust stores.
TL;DR — The private keys of 8 eMudhra intermediate certificates have been recoverable since April 2025, yet as of October 28 macOS's shipped developer tools (
git,curl,python3) still trust them, and macOS 27.2 even reverted users' manual fixes. Here's how to test and remediate.
The incident in one paragraph
CA operator eMudhra lost control of the private keys for 8 intermediate certificates due to mis-generated keys — anyone could recover them from the certificates themselves, since April 2025. The reporter proved it on October 17, 2026 by signing a message with each key. Root programs reacted fast: Firefox/Chrome blocked the certificates from October 17, Microsoft from October 20, and Apple (for Safari and apps built on its networking stack) from October 22.
The catch is clients that consume no revocation distribution like OneCRL or CRLSets and rely on software updates. Per Dennis Jackson's write-up on October 28, the tools Apple ships with macOS — git, curl, python3 — still trusted the compromised certificates because Apple hadn't purged its own bundle (/etc/ssl/cert.pem). Worse: macOS 27.2, released October 26, shipped no fix and undid users' manual workarounds.
Why developers should care
This attack hits your daily workflow directly:
git clone/git pushoverhttps://remotes — attacker-chosen code lands in your working tree, pushes can be altered in transit, and your GitHub tokens can be intercepted.curl,pip install, and any CLI HTTP client with its own bundle. Notepipreads its owncertifibundle, not/etc/ssl/cert.pem— so each tool needs its own check.- Electron apps (Slack, Discord, …) only become safe once rebuilt on a patched Electron — 42.11.16 / 43.8.1 / 44.9.1 per the incident table. Claude Code (2.1.303), VS Code (1.143.1), Docker Desktop (4.96.2), and recent Node.js/Python releases also shipped patches.
One subtlety worth knowing: the attacker's certificates were never logged to Certificate Transparency, so CT-enforcing clients (browsers) could not be silently attacked even with a poisoned trust store — but curl and most non-browser clients don't enforce CT.
Test: is your git affected?
The researchers stood up test domains signed with the compromised keys:
- A certificate error = your git is protected ✅
- It lists a commit = your git is affected ❌
For curl (run both; the -noct hosts additionally test clients that don't enforce CT):
A certificate error means protected; a page means that client's bundle still trusts the compromised intermediates.
You can even replay the full attack — cloning a repo from an impersonated GitHub:
A patched git refuses with a certificate error; a vulnerable one clones a README starting with INTERCEPTED. (A real attacker needs no curloptResolve — they redirect your traffic themselves.)
Manual remediation on macOS
Apple publishes guidance; the gist is removing the compromised roots/intermediates from /etc/ssl/cert.pem. Two caveats:
- macOS updates may revert your fix — exactly what happened with 27.2. Re-run the tests above after every update until Apple ships a real fix.
- Don't forget CI — if you run macOS runners (e.g., iOS builds), check and fix those too; this is a real supply-chain risk.
Patched versions (selected)
| Tool / runtime | Patched version | | --- | --- | | Electron | 42.11.16 / 43.8.1 / 44.9.1 | | Node.js | 26.12.1 / 24.22.1 / 22.23.4 | | Python | 3.15.2 / 3.14.10 / 3.13.18 / 3.12.16 / 3.11.18 | | Go | 1.27.3 / 1.26.10 | | Docker Engine / CLI | 29.9.2 | | VS Code | 1.143.1 | | Git for Windows | 2.56.0.3 | | Java (OpenJDK) | Still pending |
The incident site's tables cover Linux distros and libraries in full.
Action checklist
- [x] Ran the
git ls-remoteandcurltests against the researcher domains. - [ ] Updated OS trust stores and CLI tooling (
brew update && brew upgrade ca-certificateshelps on macOS). - [ ] If you applied a manual fix, left yourself a note to re-check after every macOS update.
- [ ] Patched and tested macOS CI runners.
- [ ] Compared your app's Electron / Node / Python versions against the table above.
- [ ] Until Apple ships a fix, kept sensitive operations (
git push, deploys) on trusted networks.
FAQ
Q: Does my Linux server have the same problem?
Most distros (Debian, Ubuntu, RHEL, Arch, …) shipped patched ca-certificates packages — apt upgrade or equivalent covers them. But tools with independent bundles (some Go binaries, Electron apps) need separate updates.
Q: My Python uses certifi — is that enough?
pip and requests read certifi by default, not /etc/ssl/cert.pem — so you need certifi 2026.10.19+. Tools linked against the system OpenSSL take a different path. For any sensitive tool, the domain tests above are the definitive check.
Q: Were Chrome and Firefox vulnerable?
No — both blocked the certificates from October 17, and because they enforce Certificate Transparency, the never-CT-logged attacker certificates couldn't silently attack them even before the block.