DEV Community

Cover image for Your Mac's git cloned a fake github.com without a warning: Apple, eMudhra, act three
Sam LABBE
Sam LABBE

Posted on

Your Mac's git cloned a fake github.com without a warning: Apple, eMudhra, act three

#security #git #macos #supplychain

One week ago the CA whose private key was the number 4 quit the certificate business. Browsers blocked the chain within three days of disclosure, the disclosure site shipped self-checks, and the story felt closed. It is not. Yesterday the same site published the next finding: Apple was notified on October 17, and as of October 28, the developer tools on macOS, git included, still trust the compromised certificates. Not hypothetically. On my machine, ten minutes ago, Apple's git cloned a fake github.com whose certificate was issued from the compromised chain, and it did not print a single warning. The README it fetched begins with the word INTERCEPTED.

This post is the three-legged lab I ran to pin it down: stock Apple git (intercepted), Homebrew git (safe), and the documented workaround (verified, without touching the system). Plus the detail that turns this from "lagging vendor" into something meaner: macOS 27.2, released October 26, silently undid the workaround users had applied by hand.

What is actually exposed

Safari and apps using Apple's networking frameworks were protected days ago; the blocking travels through their fast revocation channels. But the developer toolchain, git, curl, python3 and friends, validates against /etc/ssl/cert.pem without consuming revocation information, and that file still contains the affected roots. The consequences for anyone on your network path, your Wi-Fi, your ISP, your VPN provider, holding one of the eight recovered keys:

  • git clone and git pull can deliver attacker-chosen code into your working tree
  • git push traffic, including credentials and tokens, can be captured or altered
  • every HTTPS call made by the toolchain inherits the same trust gap

For CI runners and build machines on macOS, that is a supply-chain front door. Your brew install is fine (Homebrew shipped its fix days ago); the git that Xcode and the Command Line Tools give you is the one that is not.

Leg one: Apple's git, stock, intercepted

The disclosure site runs a dedicated test host, and an end-to-end demo that redirects github.com to a server presenting a github.com certificate issued from a compromised eMudhra intermediate. The fake-user@ prefix keeps real credentials out of the test. On a fully patched macOS, with the stock toolchain:

$ /usr/bin/git --version
git version 2.54.0 (Apple Git-157)

$ /usr/bin/git ls-remote https://git-emudhra.we-have-a-problem.com/
2975b9930644b321e18ecae09e29c15b955e6103    HEAD
2975b9930644b321e18ecae09e29c15b955e6103    refs/heads/main
                                        (exit 0: the compromised-signed certificate was ACCEPTED)

$ git -c http.curloptResolve=github.com:443:15.235.19.186 clone \
      https://fake-user@github.com/galadran/emudhra-git-test
Cloning into 'emudhra-git-test'...

$ cat emudhra-git-test/README.md
# INTERCEPTED: your git accepted a certificate from a compromised eMudhra CA
Enter fullscreen mode Exit fullscreen mode

That is the whole attack, minus the attacker. A clone of a github.com URL, served by someone else, accepted silently. Swap the test repo for Homebrew/brew or your company's monorepo and the "INTERCEPTED" README becomes your next brew install or your next build.

Leg two: Homebrew git, safe

Homebrew's ca-certificates package removed the affected roots days ago (2026-09-25_1), and its git links against them:

$ /opt/homebrew/bin/git --version
git version 2.56.0

$ /opt/homebrew/bin/git ls-remote https://git-emudhra.we-have-a-problem.com/
fatal: unable to access: SSL certificate OpenSSL verify result:
unable to get local issuer certificate (20)

$ /opt/homebrew/bin/git -c http.curloptResolve=... clone https://fake-user@github.com/...
fatal: SSL certificate problem: unable to get local issuer certificate
Enter fullscreen mode Exit fullscreen mode

Refused, twice. A volunteer-run project shipped the fix that a trillion-dollar company did not, which the disclosure site notes is a pattern: dozens of downstream distributions, many of them volunteer-maintained, got this done within days.

Leg three: the workaround, verified without touching the system

The documented fix is to strip the two affected roots from the file the tools read. You can prove it works before applying it system-wide, by pointing git at a cleaned copy (the official awk one-liner, minus the sudo):

awk '/^(###|===) /{skip=0}
/^=== .*\/CN=(AAA Certificate Services|emSign ECC Root CA - G3)$/{skip=1}
!skip' /etc/ssl/cert.pem > /tmp/clean-bundle.pem
# 128 certificates in, 126 out

/usr/bin/git -c http.sslCAInfo=/tmp/clean-bundle.pem \
             -c http.curloptResolve=github.com:443:15.235.19.186 clone \
             https://fake-user@github.com/galadran/emudhra-git-test
fatal: SSL certificate problem: unable to get local issuer certificate
Enter fullscreen mode Exit fullscreen mode

Same Apple git, same fake server, cleaned bundle: refused. That is the fix Apple is being asked to ship, demonstrated end to end. To apply it for real, follow the site's macOS steps, and then the catch below.

The part that should make you angry

macOS 27.2 shipped on October 26, nine days after disclosure, and according to the disclosure it did not fix the issue and undid the workaround that users had applied by hand. Apple's own guidance says system updates may revert manual trust-store changes, so anyone who cleaned their bundle on October 20 woke up re-exposed on October 27 without doing anything. If you applied the workaround, the sequence is not "fix once", it is: apply, then re-run the two self-checks after every macOS update, exactly like a regression test. For fleet owners: your MDM baseline for macOS dev machines now includes "cert.pem does not contain emSign ECC Root CA - G3 or AAA Certificate Services", asserted continuously, because the OS will fight you.

The check for your machine, tonight 

# any git, one line: error = safe, listing = vulnerable
git ls-remote https://git-emudhra.we-have-a-problem.com/

# the end-to-end proof (safe: no real credentials involved)
git -c http.curloptResolve=github.com:443:15.235.19.186 clone \
      https://fake-user@github.com/galadran/emudhra-git-test
Enter fullscreen mode Exit fullscreen mode

If you get refs and a README that says INTERCEPTED: your toolchain trusts a CA whose keys have been public for twelve days, a firm that has already left the certificate business. Clean the bundle or move your git to Homebrew's, then re-check after the next macOS update, and the one after that.

TL;DR

Act one: the key was the number 4. Act two: the CA quit the business. Act three, yesterday's finding: Apple's developer tools still trust the poisoned chain, an update shipped nine days post-discussion silently reverted users' own fixes, and my stock Mac cloned a fake github.com without one byte of warning. Homebrew's git refuses it; the awk workaround makes Apple's git refuse it; the check is one git ls-remote you can run right now. The trust fabric held for browsers and failed for builders. Your build pipeline is the perimeter now.

Sources: Apple's git still trusts the compromised eMudhra certificates · main disclosure + self-checks · Act one: the number-4 key · Act two: the exit

Top comments (0)