Apple's Git Still Trusts a Compromised CA

eMudhra's certs are compromised. The git Apple ships hasn't dropped them — so your next HTTPS clone may not come from GitHub.

Dafallah Ibrahim

— 2 min read
Share

The biggest story on Hacker News this morning: eMudhra's certificates are compromised, and the git binary Apple ships with its developer tools still trusts them. If you develop on a Mac with the stock git, the padlock on your clones means less than you think today.

Not "less in theory." Anyone who can mint an eMudhra-signed certificate can impersonate github.com to your git client — while the rest of the ecosystem has already moved to drop that CA. Your toolchain is the straggler.

Why this matters

Nearly everything you do with git rides on HTTPS: clones, fetches, submodule updates, CI checkout steps. All of it depends on TLS validating against a correct CA bundle.

The failure mode is nasty. An attacker on your network path presents a forged github.com certificate signed by eMudhra. Your git accepts it and pulls a repo the attacker authored. The clone exits 0.

And no, git's content-addressed storage doesn't rescue you. Hashes verify objects against each other, not against the real repo. On a fresh clone the attacker supplies the entire object database — history, tags, everything. One doctored Makefile later, you're running their code.

How it works

Git doesn't speak TLS itself. It hands HTTPS URLs to libcurl, which validates against a CA bundle decided at build time. Which bundle you get depends entirely on which git you installed.

The git from Xcode or Command Line Tools validates through Apple's trust configuration, which updates on Apple's schedule. Browser vendors push trust-store removals in days. A bundled toolchain can lag — and right now, that path still includes the compromised CA.

The attack needs three things: a position on your network (rogue Wi-Fi, ARP spoof, hijacked router), a DNS or proxy trick for github.com, and the cert. Then they serve you a perfect-looking repo with one extra surprise commit.

Where this helps

  • Corporate Mac fleets: hundreds of laptops cloning over HTTPS through shared offices and VPNs — one MITM point reaches all of them.
  • macOS CI runners: stock Macs with stock git, cloning over HTTPS at 2 a.m. with nobody watching the output.
  • Day-one onboarding: a new hire's first clone of your internal mirror is a fresh clone — exactly the case where the attacker controls everything.

Watch out

Switching your remote to SSH fixes you, not the tooling around you. Submodules pinned to absolute HTTPS URLs and installer scripts will still go through TLS.

Never "fix" this with GIT_SSL_NO_VERIFY=true. You'd trade a targeted risk for a universal one.

Overriding http.sslCAInfo replaces your entire trust store. Start from a current complete bundle and remove the bad roots — miss a root and unrelated hosts break in confusing ways.

Signed tags only help if you verify them with a key fetched out-of-band. For routine clones, almost nobody does.

Try it yourself

# Which git are you actually running? Apple's vs Homebrew's
which -a git && git --version

# Any CA bundle override in effect?
git config --show-origin --get-all http.sslCAInfo \
  || echo "no override — using the build's default trust"

# Pragmatic fix for GitHub work: move the remote to SSH
git remote set-url origin git@github.com:OWNER/REPO.git
git fetch --dry-run   # succeeds with zero TLS involved

TL;DR

  • What changed: eMudhra's certificates are compromised, and the git Apple ships still trusts them — forged certs can intercept HTTPS git traffic on Macs.
  • Why it matters: a MITM'd fresh clone hands the attacker your entire object store, including the build files you execute.
  • What to try today: run which -a git, switch critical remotes to SSH, and don't trust the stock bundle until Apple ships the removal.

Read more