Why git and curl on a Mac still trust the broken eMudhra CA keys: which trust store each tool reads, tested…
EXPLAINER · WEDNESDAY, OCTOBER 28, 2026
On October 28, 2026, the site tracking the eMudhra compromise reported that git, curl and python3 shipped with macOS still trust certificates from eight intermediate CAs whose private keys anyone can compute. We ran the published checks on a Mac, traced each tool to the root file it reads, and found one setting that changes the answer.
In one minute
- Eight eMudhra intermediate CAs had P-384 private keys with only one non-zero byte, so each key is one of 255 values and anyone can recover it from the public certificate.
- Browsers were covered twice: Chrome and Firefox blocked the certificates on October 17, and no certificate from these CAs was in the Certificate Transparency logs browsers rely on.
- Apple blocks them for Safari, Mail and apps on its networking and security frameworks. Its curl, git, python3, ruby, perl and openssl check /etc/ssl/cert.pem instead and skip that block, per Apple's own support page.
- On our Mac (macOS 26.5.2), Apple's git and curl accepted the test chain. The same curl rejected it when told to use Apple's SecureTransport library.
- Homebrew's git 2.49.0 links /usr/lib/libcurl.4.dylib, so on our machine installing git from Homebrew did not avoid the problem.
- Fix today with Apple's root-removal steps and recheck after every update. For git and curl only, CURL_SSL_BACKEND=secure-transport worked in our test.
What went wrong at eMudhra
A P-384 private key should be a random 384-bit number. Scott Helme found that each of the eight eMudhra keys had 47 zero bytes followed by one non-zero byte. One of them was the number 4.
That means each key is one of 255 values. You find it by computing 1 times the curve's base point, then 2 times, and so on, until the result matches the public key in the certificate. Helme reports his first recovery took less than a second on a laptop.
The eight CAs are six TLS issuing CAs (EM DV, OV and EV TLS CA, G3B and G3C) and two code signing CAs. They were created in April 2025 and cross-signed by Sectigo's AAA Certificate Services root in May 2025, so 16 certificates carry the eight keys.
eMudhra's account on Mozilla's bug ticket, as quoted by Helme, says a bug in its key ceremony script made a second, weak key pair on the HSM, and similar key names led to the wrong key being used.
Why browsers were safe and command-line tools are not
Browsers had two layers. Chrome and Firefox blocked the certificates the day they were reported, October 17, through their own revocation feeds (CRLSets, OneCRL and CRLite). And Chrome requires Certificate Transparency: a certificate must appear in public logs to be trusted. The tracker says no certificates from these intermediates appeared in CT logs.
Command-line tools usually have neither layer. They read a flat file of trusted roots, check that a chain ends at one of them, and stop. Many do not check CT or revocation. So the fix for them is to remove or distrust the roots in that file, which is why the tracker lists dozens of patched bundles, such as Python certifi 2026.10.19, the curl CA bundle of 2026-10-20, Node.js 26.12.1, Go 1.27.3, Git for Windows 2.56.0.3 and Docker Desktop 4.96.2.
The tracker says an attacker with one of these keys could impersonate any site. For git that means a clone or pull can deliver code the attacker chose, a push can be changed, and tokens sent over HTTPS can be read. It needs a network position, such as shared Wi-Fi or a compromised router.
What Apple did, and where it stops
Apple's support page says it began blocking the certificates on October 19 and the emSign ECC Root CA - G3 root on October 23, through automatic certificate configuration updates. No software update is needed for that part.
The block covers Safari, Mail and apps that use Apple's networking and security frameworks. Apple names what it does not cover: curl, git, python3, ruby, perl and openssl that ship with macOS or the Xcode Command Line Tools. They check certificates against /etc/ssl/cert.pem and do not apply Apple's block or revocation checks to chains that end at a root in that file.
Apple says changes for these tools will come in a future software update, and that a macOS update can replace /etc/ssl/cert.pem with Apple's version. The tracker says macOS 27.2, released October 26, did not fix the tools and undid the manual workaround people had applied.
What we tested on one Mac
We ran the tracker's checks on a Mac running macOS 26.5.2 on the morning of October 28. Both test servers present chains from a compromised eMudhra intermediate.
Test Mac: macOS 26.5.2 (build 25F84), October 28, 2026, 08:36 MDT
$ /usr/bin/curl -V | head -1 curl 8.7.1 (x86_64-apple-darwin25.0) libcurl/8.7.1 (SecureTransport) LibreSSL/3.3.6 ...
$ /usr/bin/git ls-remote https://git-emudhra.we-have-a-problem.com/check.git 2975b9930644b321e18ecae09e29c15b955e6103 HEAD <- accepted: affected
$ /usr/bin/curl -o /dev/null -w '%{http_code}\n' https://dv-g3b-noct-emudhra.we-have-a-problem.com/ 200 <- accepted: affected
$ CURL_SSL_BACKEND=secure-transport /usr/bin/curl -o /dev/null -w '%{http_code}\n' \ https://dv-g3b-noct-emudhra.we-have-a-problem.com/ curl: (60) SSL certificate problem: Invalid certificate chain <- rejected
Apple builds its curl with two TLS libraries. LibreSSL is the default, and it reads /etc/ssl/cert.pem, where both emSign ECC Root CA - G3 and AAA Certificate Services were still present on our machine. SecureTransport validates through Apple's trust system, which carries the block. Same binary, same server, opposite answers. The difference is the trust path, not the tool.
Apple's python3 on this Mac (LibreSSL 2.8.3) reports /private/etc/ssl/cert.pem as its trust file, and it also accepted the test server.
Homebrew did not avoid it on our machine
Installing git from Homebrew sounds like a way out. On our Mac it was not, because Homebrew's git uses Apple's libcurl:
$ otool -L /opt/homebrew/opt/git/libexec/git-core/git-remote-https | grep curl /usr/lib/libcurl.4.dylib
$ /opt/homebrew/bin/git --version git version 2.49.0
$ /opt/homebrew/bin/git ls-remote https://git-emudhra.we-have-a-problem.com/check.git 2975b9930644b321e18ecae09e29c15b955e6103 HEAD <- accepted: affected
Homebrew's own OpenSSL tools are different. Homebrew's python3 on our Mac uses OpenSSL 3.6.4 and /opt/homebrew/etc/openssl@3/cert.pem, which comes from the ca-certificates package. Ours was version 2026-08-13, older than the fix, and it accepted the test server. The tracker lists Homebrew as fixed, so updating ca-certificates should change that. We did not run the update, so we have not confirmed it.
Two ways to close it today
Option 1 is Apple's documented workaround. It needs an administrator account. Back up /etc/ssl/cert.pem, remove the emSign ECC Root CA - G3 root, and optionally remove AAA Certificate Services, which Apple warns can break sites that chain through unaffected Sectigo intermediates. The exact commands are on Apple's page and the tracker. Then verify. No output means both roots are gone:
openssl crl2pkcs7 -nocrl -certfile /etc/ssl/cert.pem | openssl pkcs7 -print_certs -noout | grep -E 'emSign ECC Root CA - G3|AAA Certificate Services' Rerun that check after every macOS update until Apple ships its command-line fix, because an update can put the file back.
Option 2 is something we found while testing, not something Apple or the tracker recommends. Setting one environment variable switched Apple's libcurl to SecureTransport. On our Mac both Apple's git and Homebrew's git then refused the bad chain, and git still reached GitHub:
Our test only: make Apple's libcurl validate through Apple's trust system
export CURL_SSL_BACKEND=secure-transport git ls-remote https://git-emudhra.we-have-a-problem.com/check.git # should now fail git ls-remote https://github.com/git/git.git HEAD # should still work
It needs no sudo, and it lives in your shell profile, not in a system file an update can replace. It only helps programs that use Apple's libcurl, so it does nothing for python3, ruby, perl or Homebrew's OpenSSL tools. We tested one Mac and a few servers. Test your own hosts before you rely on it.
macOS build machines
The tracker asks security teams to check macOS runners in CI. A runner that clones over HTTPS with Apple's git is in scope. Images are often rebuilt from a stock macOS, which can bring the roots back, so put the check, or the fix, at the start of the job rather than in the image alone.
Who is affected
| Case | Status | | --- | --- | | Safari, Mail and apps on Apple's networking and security frameworks | Blocked by Apple since October 19, per Apple. The tracker lists Apple's block on October 22. | | Apple's git and curl (default LibreSSL backend) | Still trust the chain. Accepted the test servers on our Mac on October 28. | | Apple's python3, ruby, perl and openssl | Read /etc/ssl/cert.pem, per Apple. python3 accepted the test server on our Mac. | | Homebrew git | Links Apple's libcurl. Version 2.49.0 accepted the test server on our Mac. | | Homebrew OpenSSL tools, such as Homebrew python | Depends on the ca-certificates version. Ours, 2026-08-13, accepted. The tracker lists Homebrew as fixed. | | Chrome and Firefox | Blocked October 17. | | Windows | Microsoft blocked the certificates October 20, per the tracker. |
What to do
- On every Mac you code on, run git ls-remote https://git-emudhra.we-have-a-problem.com/check.git. A certificate error means you are protected; a listed commit means you are not.
- Apply Apple's /etc/ssl/cert.pem steps, then rerun the check after every macOS update until Apple ships its command-line fix.
- If you cannot use sudo, test CURL_SSL_BACKEND=secure-transport for git and curl, and confirm with the same check.
- Update Homebrew's ca-certificates and any language bundle the tracker lists as fixed, such as certifi, Node.js or Go.
- Add the check to macOS CI jobs so a rebuilt image cannot quietly reopen the hole.
What is still unknown
- Whether anyone used these keys. The tracker says it does not know.
- When Apple ships the command-line fix. Apple says only that it is coming in a future software update.
- We tested one Mac on macOS 26.5.2, not 27.2. The claim that 27.2 undid the workaround is the tracker's, and we did not reproduce it.
- The SecureTransport setting is our own test, not guidance from Apple, curl or the tracker. SecureTransport is an older Apple TLS library and we did not test it against every kind of server.
- Whether newer Homebrew git builds still link Apple's libcurl. We checked only 2.49.0.
- The exact date of Apple's block. Apple's page says October 19; the tracker's timeline says October 22.
Sources
- [Dennis Jackson and contributors, "Ten days later, Git on macOS still trusts the compromised eMudhra certificates" (October 28, 2026)](https://emudhra.we-have-a-problem.com/apple.html) — the original report
- Apple, "About the compromised eMudhra intermediate CAs" (October 23, 2026)
- eMudhra intermediate CA compromise tracker: timeline, fixed software, macOS workaround
- Scott Helme, "Eight Bits of Trust; eMudhra's CA keys cracked in milliseconds" (October 20, 2026)
Today's full edition: AI News Report · every headline, every morning.