macOS command-line tools still trust the compromised eMudhra certificates

Apple was told about the eMudhra certificate compromise on 17 October. On 28 October, the git, curl and python3 binaries that ship with macOS still trusted the compromised intermediates. The macOS 27.2 update, released 26 October, did not fix this. It also removed the manual workaround that affected users had applied, putting them back to vulnerable.

Apple has fixed the visible part. Safari and anything else built on its networking framework no longer trust the compromised certificates. The command-line tools engineers use to move code around were left on the old trust store. Dozens of other projects, many maintained by volunteers, shipped fixes days ago.

An attacker gets this: any HTTPS connection those tools make can be intercepted by anyone sitting on the network path. For git over https:// remotes, a clone or pull can hand you attacker-chosen code, a push can be altered in transit, and any credential sent along the way, a GitHub token for instance, can be read off the wire. curl and python3 are exposed the same way, which covers a large share of install scripts, package tooling and CI steps that shell out to one of the three.

Checking your tools

You can confirm whether your git trusts the bad certificates in one command:

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

A certificate error is the good outcome: your git is rejecting the compromised chain. If git prints a commit hash, it accepted a certificate issued under the compromised CA, and your connections to GitHub or any other https:// remote can be tampered with.

To watch the interception end to end:

git -c http.curloptResolve=github.com:443:15.235.19.186 clone https://[email protected]/galadran/emudhra-git-test

The -c option redirects github.com to a test server for that one command, and the server answers with a github.com certificate issued by one of the compromised eMudhra intermediates. A patched git refuses with a certificate error. A vulnerable one finishes the clone and drops a README.md that starts with INTERCEPTED. Keep the fake-user@ prefix on any repository you substitute in; without it, git sends your real GitHub credentials to the test server. A live attacker needs none of this scaffolding. The -c flag only stands in for the traffic redirection they would perform themselves.

For curl:

curl https://dv-g3b-noct-emudhra.we-have-a-problem.com/
curl https://dv-g3b-aaa-noct-emudhra.we-have-a-problem.com/

A certificate error again means you are protected.

Until Apple ships a fix

The affected roots can be pulled out of /etc/ssl/cert.pem by hand, and the project’s main page documents the steps. macOS 27.2 showed the catch: Apple’s own guidance says updates may revert the change. The workaround is not one-and-done. After every macOS update, rerun the checks above and reapply the removal if the roots have come back. That loop holds until Apple removes the compromised roots from the trust store it ships.

The exposure worth escalating is CI. If any build or release pipeline runs on macOS runners, hosted macOS images or self-hosted Mac hardware that clones over https:// or curls an install script, those runners have been fetching code and artefacts through a trust store that accepts the compromised CA. Audit which pipelines touch macOS and what they pull.