Apple Blocked the Compromised eMudhra Certificates in Safari on October 19. The git and curl That Ship With macOS Still Trust Them. Here Is the 15-Minute Checklist.
On October 17, a researcher proved that the private keys behind eight intermediate certificate authorities run by eMudhra could be recovered from the public certificates themselves. Chrome and Firefox blocked them the same day, Apple followed on October 19 and Microsoft on October 20. But Apple's own notice says the command-line tools that ship with macOS, including curl, git and python3, can still accept those certificates until a future software update. If your deploy scripts, backups or webhooks make TLS calls from a Mac or a container, the browser fix does not cover you.
What actually broke
The keys were not stolen. According to The Hacker News, eMudhra said a flaw in its April 30, 2025 key ceremony produced a second, weak set of keys alongside the intended ones, and that weak set ended up in the browser root stores. Aikido's analysis found that each of the eight private keys is below 256, and one is 4. A properly generated key of this type should come from roughly 10^115 possible values, so an attacker needs at most 256 guesses per key. That is a laptop-and-a-second problem, not a nation-state problem.
Six of the eight intermediates issue TLS certificates, which is the dangerous half. The other two issue code-signing certificates. Anyone holding a key can sign a certificate for any domain that chains to that intermediate, so a machine that still trusts the chain would accept a forged site as real.
The honest context: eMudhra said only one of the eight was deployed in production and none had issued end-entity certificates, and Chrome's certificate transparency check found no TLS certificates chaining to the six TLS intermediates before the block. Nobody has shown the keys were used in an attack. That lowers the odds of harm. It does not lower the cost of closing the gap, which is small.
Why your Mac is only half covered
Apple began blocking 12 of the affected TLS certificates on October 19 through automatic configuration updates, and added emSign ECC Root CA - G3 on October 23. That covers Safari, Mail and apps that use Apple's networking and security frameworks. It does not cover tools that read the file /etc/ssl/cert.pem. Apple's support page lists curl, git, python3, ruby, perl and openssl among them, and says a fix will come with a future software update that also updates that file. There is no release date or macOS version on the page.
This is why the Hacker News post about it, titled "Apple's git still trusts the compromised eMudhra certificates," collected more than 1,000 points on October 28. The browser story was handled quickly. The tools a solo operator actually scripts with were not.
Apple's page also describes a manual workaround: back up the file, remove emSign ECC Root CA - G3, and optionally remove AAA Certificate Services to also stop the Sectigo cross-signed copies. The caveats are real. Removing roots can break legitimate sites that chain through them, and a macOS update can overwrite the file, so you would have to repeat it. I would test before touching anything.
The 15-minute checklist
Start with a test, not a patch. Aikido published two URLs on a test domain that serve certificates chained to the compromised intermediates. From each place you make outbound TLS calls, run this:
curl -sS -o /dev/null -w "HTTP %{http_code}\n" https://dv-g3b-emudhra.we-have-a-problem.com/
curl -sS -o /dev/null -w "HTTP %{http_code}\n" https://dv-g3b-aaa-emudhra.we-have-a-problem.com/
An SSL error with HTTP 000 means that client rejects the bad chain, which is what you want. A 200 means it still trusts it. Run it on your Mac's system curl, inside your main container, and on your server.
Then work down the stack. Runtimes bundle their own roots, so each needs its own release:
- Node.js: update to 26.12.1, 24.22.1 or 22.23.4.
- Go: rebuild against 1.27.3 or 1.26.10. Go 1.25 and older get no fix.
- Python: update
certifi. Rust's webpki-roots needs 1.0.10 or later. - Linux boxes: update the
ca-certificatespackage, and check your distribution's advisory for the patched version. - Containers: rebuild with
docker build --pull --no-cache. A running container keeps the old bundle until it is restarted from a new image, which is the one people forget.
If you are on Red Hat Enterprise Linux, there is no package yet, only a workaround in advisory RHSB-2026-012. Cloudflare customers who run their own origins or mutual TLS may also need to update trust stores.
Where I could be wrong
Maybe this is a lot of effort for a bug that was never exploited. With one of eight CAs in production and no certificates issued, the realistic risk to a small app today is low, and I would not drop a launch for it. The reason I would still spend the fifteen minutes is asymmetry. The check costs a quarter of an hour. A forged certificate on a deploy script that pushes code or reads secrets is the sort of attack that needs no skill once someone has the keys, and those keys are recoverable by anyone who looks.
What I'd actually do
Today I would run the two curl tests from my Mac and from my production container image. If both return an SSL error, I am done and I write the date in my notes. If either returns 200, I update the runtime or rebuild the image first, because that is the quick fix, and I apply Apple's file workaround on the Mac only if I rely on system git or curl for anything touching production. Then I would set a reminder to remove the workaround once Apple's update lands. The thing I would not do is assume Safari getting the block means my scripts have it too.
Author
Lukas
@lukcombinator