Apple's macOS git and curl still trust compromised eMudhra certificates
A site published by Dennis Jackson, dated 28 October 2026, says Apple was notified of the eMudhra incident on 17 October. As of 28 October, it says, the developer tools Apple ships with macOS, including git, curl and python3, still trust the compromised eMudhra certificates.
The site adds that macOS 27.2, released on 26 October, did not fix the issue. Worse, it undid the workaround users had applied by hand, leaving them vulnerable again. Meanwhile, the site says, dozens of other projects, many run by volunteers, shipped fixes days ago.
The stated consequence is that anyone can intercept any HTTPS connection these tools make. For git, clones and pulls from https:// remotes can deliver attacker-chosen code, pushes can be altered in transit, and credentials such as GitHub tokens can be intercepted.
The page includes a way to test this. Running git ls-remote against a check repository on the site's own domain tells you whether your git is affected: a certificate error means it is protected, while a listed commit means it is affected and connections to GitHub or any other https:// git remote can be intercepted and tampered with. For an end-to-end demonstration, a second command clones a repository from a test server impersonating GitHub. The -c option redirects github.com to that server for one command only, and the server presents a github.com certificate issued by one of the compromised eMudhra intermediates. A patched git refuses with a certificate error; if the clone succeeds, the README.md starts with INTERCEPTED. The site stresses that a real attacker would not need the extra option, because anyone on the network path between the user and GitHub can redirect the traffic. The demo can be pointed at any other repository, public or private, but the fake-user@ prefix must stay, otherwise git would send the user's GitHub credentials to the test server.
curl, python3 and the other tools Apple ships are affected in the same way. For curl, the page gives two URLs on the site's domain to fetch; a certificate error means curl is protected. The site says Apple has already protected Safari and other apps built on its networking framework.
The site's recommendation is that Apple ship a fix for macOS developers as soon as possible, for example by removing the affected roots from /etc/ssl/cert.pem. Until then the roots can be removed by hand, following the macOS workaround on the site's main page. Citing Apple's guidance, the page says macOS updates may revert the fix, so developers need to repeat the checks and the workaround after every update. Security teams should also consider whether macOS runners are used in CI or other build infrastructure and evaluate the supply chain risk. The site describes itself as the work of many community contributors, with source on GitHub under the Apache License 2.0.
Key facts
- Apple was notified of the eMudhra incident on 17 October; as of 28 October, git, curl and python3 shipped with macOS still trust the compromised certificates, per the site.
- macOS 27.2, released on 26 October, did not fix the issue and undid the workaround users had applied by hand.
- The stated impact: anyone can intercept HTTPS connections made by these tools, including git clones, pulls, pushes and credentials such as GitHub tokens.
- The site offers a one-line git check and a demo clone from a test server impersonating GitHub; a certificate error means the tool is protected.
- Dozens of other projects shipped fixes days ago, while Safari and apps on Apple's networking framework are already protected.
Why it matters
The claim is that the tools developers use every day to fetch code and authenticate to GitHub on a Mac will accept forged certificates from the compromised eMudhra intermediates. That would put code delivered by git clones and pulls, and the credentials sent over HTTPS, within reach of anyone positioned on the network path. The site also makes the contrast with others: dozens of projects, many run by volunteers, shipped fixes days ago, while Apple was notified on 17 October and, per the site, had not fixed its developer tools by 28 October.
Who it affects
Developers using the git, curl and python3 that Apple ships with macOS, especially anyone who applied the manual workaround and then installed macOS 27.2. Security teams are also pointed at macOS runners in CI or other build infrastructure, where the site says the supply chain risk should be evaluated. Safari and other apps built on Apple's networking framework are described as already protected.
How to use it
The page gives a quick test: run git ls-remote https://git-emudhra.we-have-a-problem.com/check.git. A certificate error means git is protected; a listed commit means it is affected. For curl, fetch the two test URLs the page lists; a certificate error means curl is protected. The workaround is to remove the affected roots by hand, with steps on the site's main page. Because Apple's guidance says macOS updates may revert the fix, the checks and the workaround need repeating after every update until Apple ships a fix. The site's own suggested fix for Apple is removing the affected roots from /etc/ssl/cert.pem. When running the demo clone, keep the fake-user@ prefix, or git would send your GitHub credentials to the test server.
How solid is it
The page is a primary-style advisory with a reproducible demo, published by Dennis Jackson and built by many community contributors, with source on GitHub. The dates (notification on 17 October, macOS 27.2 on 26 October, status as of 28 October) are stated by the site itself. No Apple statement is quoted beyond a reference to Apple's guidance on updates reverting the fix.
Risks and caveats
The page does not explain what the eMudhra incident itself was or how the certificates were compromised. It gives no evidence of an attack in the wild; interception is shown only with a test server. It does not say which macOS versions other than 27.2 are affected, does not name the other projects that shipped fixes, and gives no date for an Apple fix. The demo redirects only one command to the test server, and users who run it on other repositories must keep the fake-user@ prefix to avoid sending real credentials.
“Anyone can intercept any HTTPS connection these tools make.”
— emudhra.we-have-a-problem.com, site published by Dennis Jackson