Is Your Mac's Git Still Trusting the Hacked eMudhra Certificates?

Apple blocked eMudhra's compromised CA certificates in Safari and Mail on October 19, 2026. If you only use the browser, you're covered. But open Terminal and run git clone or curl against a site chained to one of those certificates, and as of this week your Mac will happily trust it anyway. That gap has been public for over a week and Apple still hasn't shipped a real fix for it.

Here's what happened, why your terminal is the weak link, and the exact commands to check and patch it yourself.

What actually happened to eMudhra's certificates

eMudhra is an Indian certificate authority, one of a few dozen organizations the entire internet trusts to vouch for HTTPS. In April 2025, during a key generation ceremony for eight intermediate CA certificates, a bug in their scripting produced a second, much weaker set of private keys alongside the real ones. Those weak keys are what got published into the certificates trusted by every major browser.

How weak? The keys used P-384 elliptic curve crypto, which is supposed to involve numbers with roughly 115 digits. Instead, several of eMudhra's private keys turned out to be small enough to guess by hand. One was literally the number 4. Others were 56, 66, 115, 155, 156, 230, and 237. A researcher spotted the pattern on October 17, 2026 while digging through public certificate transparency logs, and once you see one weak key in a batch, you check the rest.

Anyone with those numbers could mint a certificate for any domain and have it trusted as if it came from a real CA. No evidence has surfaced of anyone actually doing that in the wild, but the capability was sitting in public CT logs for over a year before it got caught.

How fast did browsers actually respond

Pretty fast, honestly. The Chrome Root Program got the report at 18:05 UTC on October 17 and had a CRLSet update blocking the affected SPKI hashes live by 19:45 UTC, less than two hours later. Android devices picked up the equivalent block through Google Play Services by 22:00 UTC that same night. Mozilla blocked the certs through Firefox's OneCRL mechanism on the same day and shipped Firefox 158.0.1 on October 20 to make it permanent. Chrome pulled the trigger on removing the whole emSign ECC Root CA - G3 from its root store on October 20, landing to users around October 27.

Apple moved slower, and only partially. Safari, Mail, and anything built on Apple's native networking frameworks started rejecting the bad certificates on October 19, delivered as a quiet trust-store update with no OS update required. Apple added a second wave of protection, blocking the root CA itself, on October 22-23. That part works well and most Mac and iPhone owners never had to do anything.

The part that doesn't work is everything that doesn't go through Apple's frameworks.

Why git, curl and python3 are still exposed

macOS runs two separate certificate trust systems side by side. There's Apple's own trust evaluation engine, the one Safari and Mail use, which gets updated automatically and already knows about this incident. And there's a plain file at /etc/ssl/cert.pem, a flat bundle of root certificates that ships with the OS and that the command-line tools (curl, git, python3, ruby, perl, openssl) read directly instead of asking Apple's trust engine anything.

Those tools don't check revocation lists. They don't know about Apple's block. They just see a certificate chaining up to a root in that file and call it good. Security researcher Ryan Shea confirmed this on his own machine running macOS 26.7.1 and 27.0.1 and posted the proof on X. The file hasn't been updated to drop the compromised intermediates, so the command-line tools you use every day for git clone, pip install, and API calls are still extending trust to certificates every browser on the planet has already blacklisted.

Here's the part that'll annoy you more: macOS 27.2, which shipped October 26, reset the manual fixes some developers had already applied. If you patched this yourself last week, check it again.

How to check if your Mac is affected

Run these before you assume anything. The maintainers behind emudhra.we-have-a-problem.com set up live test endpoints specifically for this.

# Test git
git ls-remote https://git-emudhra.we-have-a-problem.com/check.git

# Test curl
curl -v https://dv-g3b-noct-emudhra.we-have-a-problem.com/

If you get a certificate error, you're protected. If git lists refs or curl connects successfully, your command-line tools still trust the compromised chain. You can also check directly:

openssl crl2pkcs7 -nocrl -certfile /etc/ssl/cert.pem | openssl pkcs7 -print_certs -noout | grep -E 'emSign ECC Root CA - G3|AAA Certificate Services'

If that prints anything, the compromised roots are still sitting in your trust bundle.

How to fix it yourself

Apple's own support page (149555) now documents a manual workaround, which tells you everything about how confident they are in an imminent automatic fix. Back up the file first, then strip the bad root:

# 1. Back up the original
[ -e /etc/ssl/cert.pem.orig ] || sudo cp -p /etc/ssl/cert.pem /etc/ssl/cert.pem.orig

# 2. Remove emSign ECC Root CA - G3
t=$(mktemp) && awk -v s='=== /C=IN/OU=emSign PKI/O=eMudhra Technologies Limited/CN=emSign ECC Root CA - G3' \
  '/^(===|###) /{skip=0} $0==s{skip=1} !skip' /etc/ssl/cert.pem > "$t" && \
  [ -s "$t" ] && sudo install -m 0644 -o root -g wheel "$t" /etc/ssl/cert.pem; rm -f "$t"

# 3. Optional: also remove the Comodo/AAA cross-sign path
t=$(mktemp) && awk -v s='=== /C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA Limited/CN=AAA Certificate Services' \
  '/^(===|###) /{skip=0} $0==s{skip=1} !skip' /etc/ssl/cert.pem > "$t" && \
  [ -s "$t" ] && sudo install -m 0644 -o root -g wheel "$t" /etc/ssl/cert.pem; rm -f "$t"

# 4. Verify it's gone
openssl crl2pkcs7 -nocrl -certfile /etc/ssl/cert.pem | openssl pkcs7 -print_certs -noout | grep -E 'emSign ECC Root CA - G3|AAA Certificate Services'

Step 4 should print nothing. If you need to undo it, sudo cp /etc/ssl/cert.pem.orig /etc/ssl/cert.pem restores the original. Developer Maarten Klasen packaged the same steps into a small script on GitHub (mklasen/macos-emudhra-fix) if you'd rather not hand-type awk commands, but read it before running anything with sudo, as you always should.

The annoying catch: any macOS update can quietly restore cert.pem to Apple's shipped version, which puts the weak root right back. Re-run the check command after every system update until Apple actually ships this in a real patch instead of a support article.

Don't forget pip

If you use Python, pip3 and pip inside virtual environments built from the system Python carry their own separate, outdated copy of root certificates through the certifi package, independent of /etc/ssl/cert.pem. Fixing the OS file doesn't fix this. Upgrade separately:

• pip to 26.2.2 or later
• certifi to 2026.10.19 or later
• uv to 0.13.4 or later, if you use it

python3 -m pip install --upgrade pip certifi

If you installed git or curl through Homebrew rather than using Apple's built-in versions, you're probably in better shape already since Homebrew's formulas link against their own OpenSSL cert store, not Apple's file. Run which curl and which git to confirm which binary you're actually using before you assume you're fixed or assume you're exposed.

Was this really that bad

Yes and no. There's no confirmed exploitation, and the window for a real-world attack required someone to notice the weak keys first, which a researcher did before anyone malicious apparently got there. But eMudhra didn't catch its own key ceremony bug for 18 months, and it only came to light because someone was willing to pore over certificate transparency logs for fun. The company has since announced it's exiting the global SSL/TLS certificate business entirely, which tells you how seriously the browser root programs took it. Roughly 30,000 certificates now need replacing.

What bugs me is the Apple side specifically. Chrome fixed its exposure in under two hours. Apple took two days for the part that matters to most users, and more than a week later still hasn't fixed the part that matters to every developer running git and curl on a Mac. Publishing an awk one-liner as the official remediation for a certificate authority compromise, on an OS used by a meaningful share of the engineering population, isn't a great look. If you're a Mac-using developer, don't wait for the automatic fix. Run the check, apply the workaround, and put a reminder on your calendar to re-check it after your next system update.

For more on recent supply-chain and CA-adjacent security scrambles, see our coverage of the LiteLLM backdoor that forced a mass key rotation, the OpenCode breach that pushed teams to rotate API keys, and the HTTP2Shell Brotli CVE that hit a similarly overlooked piece of infrastructure.

Watch