Quick Answer: Yes, on many Macs. As of 28 October 2026, the developer tools Apple ships with macOS, including git, curl and python3, still trust the compromised eMudhra certificates. Run
git ls-remoteagainst a test host. A certificate error means git is protected. If git lists a commit, it is affected, and you should remove the affected roots by hand until Apple ships a fix.
Apple was told about the eMudhra incident on 17 October. Eleven days later, as the advisory at emudhra.we-have-a-problem.com documents, the git, curl and python3 binaries that ship with macOS still accept the compromised certificates. Dozens of other projects, many run by volunteers, shipped fixes days ago. Apple's own Safari and apps built on its networking framework are protected, which makes the gap in its command-line tools easy to miss.
Why Apple's Command-Line Tools Matter More Than You Think
Every HTTPS connection depends on a trust store: a list of root certificates your system accepts as authorities. When a server presents a certificate, the client walks the chain up to a root in that list. If the chain ends at a root that should never have been trusted, the client accepts whatever the attacker presents.
That's the problem here. Anyone who can sit on the network path can impersonate a site like github.com, and git will accept it. The advisory spells out what follows. Clones and pulls from https:// remotes can deliver attacker-chosen code. Pushes can be altered in transit. Your credentials, such as GitHub tokens, can be intercepted.
Most developers assume that a git clone over HTTPS is as safe as the padlock in their browser. In this case, that assumption is wrong. Safari has been fixed, but the command-line tools use the system trust store directly, so they inherit the bad trust.
Check Your Git and curl in Under a Minute
You don't need to trust anyone's word on this. Run the checks yourself. The results are easy to read because the advisory defines the healthy outcome as an error.
-
Open Terminal and run the git check:
git ls-remote https://git-emudhra.we-have-a-problem.com/check.git -
Interpret the result. A certificate error means your git is protected. If git lists a commit, your git accepts the compromised chain, and your GitHub connections are exposed too.
-
Run the two curl checks:
curl https://dv-g3b-noct-emudhra.we-have-a-problem.com/curl https://dv-g3b-aaa-noct-emudhra.we-have-a-problem.com/ -
Compare the outcomes against this table:
| Tool | Command | Protected result | Affected result |
|---|---|---|---|
| git | git ls-remote on the git-emudhra check repo | Certificate error | Lists a commit |
| curl (first host) | curl on dv-g3b-noct-emudhra host | Certificate error | Request completes without a certificate error |
| curl (second host) | curl on dv-g3b-aaa-noct-emudhra host | Certificate error | Request completes without a certificate error |
The advisory also includes a fuller end-to-end demonstration that clones a repository from a test server posing as github.com. It's worth reading on the advisory page if you want to see the attack play out. Keep in mind that a real attacker wouldn't need any special options. Anyone on the network path between you and GitHub can redirect your traffic.
Why the Latest macOS Update Made Things Worse
This is the counter-intuitive part, and it's where most advice goes wrong. The usual rule is to install security updates. In this case, that rule can leave you exposed.
macOS 27.2 was released on 26 October. It did not fix the issue. It also undid the workaround that many users had applied by hand, which put them back in the vulnerable state. Consider what that means in practice. If you patched your trust store last week and then accepted an update this week, your machine may have quietly returned to the state that existed before you fixed it.
Here's the cause-and-effect chain. Your manual edit lives in a system file. A macOS update rewrites that file. The rewrite restores the compromised roots. Your git and curl then accept the bad chain again, and nothing in your daily workflow warns you.
That's why the advisory's guidance is to repeat the checks above after every macOS update. Treat the check as part of your update routine, not a one-time task.
The Workaround: Removing Roots by Hand
The fix Apple should ship is to remove the affected roots from the system trust bundle, for example /etc/ssl/cert.pem. Until that happens, the advisory says the affected roots can be removed by hand, and the step-by-step is on the advisory's main page.
Before you edit anything, weigh the trade-off. You are changing a file that macOS manages. That gives you immediate protection, but it also means you own the consequences. An update can overwrite your change, and a mistake in that file can break HTTPS for other tools. Back up the file before you touch it, follow the advisory's steps exactly, and rerun the checks afterward.
It's also worth noting what the workaround doesn't do. It fixes the trust store on that one machine. It doesn't fix other devices on your network, and it doesn't protect builds that run on machines you don't manage.
Why Other Projects Moved Faster
Dozens of projects shipped fixes within days, many of them maintained by volunteers. Apple has far more resources, so the gap is hard to explain. The advisory doesn't speculate about Apple's internal timeline, and neither should you. What matters is the practical result: the open-source projects you depend on may already be patched, while the system binaries underneath them are not.
That gap is also why the advisory asks Apple to act as soon as possible. Shipping a fix for macOS developers, such as removing the affected roots from the system bundle, closes the hole for everyone at once. Individual workarounds protect only the people who find them.
Here's where it gets interesting for teams. Your vendored binaries and your system tools can disagree about what's trusted, and you may not know which of them you rely on.
CI Runners and Supply-Chain Risk
If your organisation builds on macOS runners, this is a supply-chain issue, not just a laptop issue. A build step that clones a dependency, fetches a package, or pulls a container definition over HTTPS can be fed attacker-chosen content. The result can be a compromised artifact that looks perfectly normal in your pipeline.
Security teams should take three steps:
- Inventory every macOS runner and image in your CI and build infrastructure.
- Run the git and curl checks on each image, not just on developer laptops.
- Re-run the checks whenever a runner image is rebuilt or updated, because the image update can restore the bad roots.
That said, there's a real catch. Runner images are often rebuilt automatically, so a clean image today may not be clean next week. Make the check a gate in your image pipeline rather than a one-time audit.
Frequently Asked Questions
What are compromised eMudhra certificates?
Compromised eMudhra certificates are certificates tied to the eMudhra certificate authority that have been compromised, so attackers can use them to impersonate HTTPS sites. The issue is serious on macOS because Apple's git, curl and python3 still trust them as of 28 October 2026. Check your tools with git ls-remote and curl. A certificate error means you're protected.
How do I check if git on my Mac is affected?
Run git ls-remote https://git-emudhra.we-have-a-problem.com/check.git in Terminal. A certificate error means git is protected. If git lists a commit, your git trusts the compromised chain, and your GitHub connections can be intercepted. Repeat the check after every macOS update, because updates can restore the bad roots.
Why does git on macOS still trust compromised eMudhra certificates after an update?
macOS 27.2, released on 26 October, did not fix the problem. It also undid manual workarounds, which restored the affected roots in the system trust file. Git and curl read that file, so they trust the compromised chain again. Updates can therefore revert a fix you made by hand.
Can I just wait for the next macOS update?
No. Waiting leaves your git, curl and python3 trusting attacker-controllable certificates. Apple has not shipped a fix that holds across updates yet. Check now, apply the manual workaround from the advisory's main page if you're affected, and verify it again after each update.
Protect Your Git Remotes Today
The most actionable takeaway is simple: run the git check on your primary Mac, and treat a commit in the output as a stop-and-fix signal. Don't assume the padlock in your browser covers your terminal, and don't assume a macOS update made things safer. If you're on a macOS CI runner, add the same check to your image pipeline before the next build. Pass this along to whoever manages your macOS runners, and ask them to run git ls-remote on their images this week.