If you use the git, curl or python3 that ship with macOS, they still trust eight compromised eMudhra certificates. Updating macOS won’t fix it, and neither will fixing it once by hand.
In Apple’s git still trusts the compromised eMudhra certificates, Dennis Jackson shows how anyone on your network path can serve you a fake GitHub. Below are the two obvious fixes, why each fails, and the one that holds until Apple ships a patch.
Table of Contents
- What’s exposed
- Plan A: wait for the macOS update
- Plan B: remove the bad roots once
- Plan C: fix it, then check after every update
- Is this overblown?
- What to do this week
- FAQ
- Sources
What’s exposed
The private keys of eight eMudhra intermediate certificates were compromised. The incident page says they were generated incorrectly, so anyone can recover them from the certificates. Firefox and Chrome blocked them on October 17, and Apple products followed on October 22.
The block doesn’t reach the command-line tools. Apple’s own statement says curl, git, python3, ruby, perl and openssl check certificates against /etc/ssl/cert.pem. For chains that end in a root in that file, they skip Apple’s block and the revocation check.
Jackson spells out what that means for git. A clone or pull over https:// can deliver code an attacker picked. A push can be altered in transit, and your GitHub token can be read.
Plan A: wait for the macOS update
Apple was told on October 17. macOS 27.2 shipped on October 26 and didn’t fix it. Apple’s statement says the file “will be updated in a future macOS update”, with no date.
Waiting leaves every Mac exposed in the meantime. Safari is already protected, which makes the gap easy to miss: the browser test looks fine while git is still open.
Plan B: remove the bad roots once
The workaround is to remove the affected roots from /etc/ssl/cert.pem. The incident page walks through the steps.
Doing it once doesn’t hold. Per Jackson, macOS 27.2 undid the workaround users had applied, which left them exposed again. Apple’s own guidance warns that updates may revert it.
Plan C: fix it, then check after every update
What holds is the workaround plus a check you repeat. Jackson’s test for git takes one command:
git ls-remote https://git-emudhra.we-have-a-problem.com/check.git
A certificate error means your git is protected. If git lists a commit, it’s exposed. 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/
Run them after every macOS update until Apple ships the fix. Jackson also asks security teams to check macOS CI runners, since a build machine that trusts these certificates is a supply chain risk.
One developer in the discussion went further and pointed /etc/ssl/cert.pem at the MacPorts certificate bundle, then showed curl rejecting the test site. Whether an update overwrites that link too is exactly what the check is for.
Is this overblown?
Some developers think so. An attacker needs to sit between you and GitHub first, one of them argued. Another replied that a phishing link, DNS poisoning or a hacked Wi-Fi access point is enough to get there.
Moving git remotes to SSH came up as well, since SSH doesn’t rely on certificate authorities. The reply: SSH has its own weak spot, because most people accept the host key on first connect without checking it.
I’d still use SSH for git where I can. It removes this whole class of problem for git, though curl and python3 stay exposed.
What to do this week
- Run the git and curl checks above on your Mac.
- If either connects, remove the affected roots by hand, following the incident page.
- Add both checks to whatever you do after a macOS update.
- Run them on macOS CI runners and build machines too.
- Switch git remotes to SSH where you can, and verify the host key fingerprint the first time.
FAQ
Does this affect Homebrew git and curl?
The incident page lists Homebrew’s ca-certificates package as patched. Tools that use a different trust store behave differently, so run the same checks against the binary you actually use.
Is Safari affected?
No. Per Jackson, Apple already protects Safari and other apps built on its networking framework. The gap is in tools that read /etc/ssl/cert.pem.
Will a macOS update undo my fix?
It can. macOS 27.2 undid the manual workaround, and Apple’s guidance says updates may revert it. Repeat the check after every update.
Does SSH protect my git remotes?
SSH doesn’t use certificate authorities, so these certificates don’t affect it. It relies on trusting the host key, so check the fingerprint on first connect.
Are other tools affected?
Yes. Apple’s statement names curl, git, python3, ruby, perl and openssl. The incident page adds apps that ship their own certificate bundle, including Electron apps such as Slack and Discord until they update.
Do I need to check CI?
If you build on macOS runners, yes. Jackson asks security teams to look at macOS machines in CI and build infrastructure.
Sources
- Article: Apple’s git still trusts the compromised eMudhra certificates by Dennis Jackson.
- Incident page: eMudhra Intermediate CA Compromise.
- Apple’s statement: support.apple.com/en-us/149555.
- Discussion: https://news.ycombinator.com/item?id=50271640, for the MacPorts bundle, the threat-level debate and the SSH trade-off.