Git on macOS still trusts eMudhra's compromised certificates

What Apple still hasn't fixed

Apple was notified on October 17, 2026 about the incident involving compromised certificates issued by eMudhra intermediaries, a certificate authority used to validate HTTPS connections. According to a report published on October 28 by the site emudhra.we-have-a-problem.com, maintained by Dennis Jackson with contributions from the community, the development tools that Apple distributes with macOS, including git, curl, and python3, still trust these compromised certificates.

The problem isn't theoretical. As long as these roots remain in the system's trust list, anyone capable of intercepting network traffic between the developer and a server like GitHub can present a valid-looking fake certificate, and the tools will accept the connection as legitimate.

The October 26 update made things worse

The report points to an aggravating factor: macOS 27.2, released on October 26, didn't fix the problem and also undid the manual workaround developers had applied on their own, which removed the compromised roots from the /etc/ssl/cert.pem file. In practice, anyone who had protected themselves became vulnerable again after updating the system.

Apple advises, according to its own documentation cited in the report, that macOS updates can revert the manual fix, which forces anyone relying on it to repeat the procedure and the verification tests after every system update, until the company publishes a definitive fix.

In contrast, the report mentions that dozens of other projects, many maintained by volunteers, had already fixed the problem days earlier. Apple, according to the text, has already protected Safari and other apps built on its native networking framework, but not the command-line tools used by developers.

How to check if your git is vulnerable

The site published a direct test. Run the command below on any macOS machine:

git ls-remote https://git-emudhra.we-have-a-problem.com/check.git

If git returns a certificate error, your installation is protected. If it lists a commit, your installation is vulnerable, and any connection to https:// remotes, including GitHub, can be intercepted and altered in transit.

To test curl, the commands are:

curl https://dv-g3b-noct-emudhra.we-have-a-problem.com/
curl https://dv-g3b-aaa-noct-emudhra.we-have-a-problem.com/

A certificate error in both cases indicates that curl is protected. python3 and the other tools Apple distributes are affected the same way, since they share the same system trust chain.

The attack in practice

The report provides a demonstration that simulates a real interception against GitHub. In a temporary directory, the following command forces github.com to resolve to a test server that presents a certificate for github.com issued by one of the compromised eMudhra intermediaries:

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

A patched git refuses the connection with a certificate error. If the clone completes, the downloaded repository includes a README.md starting with INTERCEPTED, proof that the content came from the fake server, not from the real GitHub.

The fake-user@ prefix in the URL is intentional: without it, git would send real GitHub credentials, such as access tokens, to the impostor server. The report stresses that, in a real attack, the attacker doesn't need the -c http.curloptResolve option: anyone in the network path between the developer and GitHub, whether on public Wi-Fi, a compromised corporate network, or a malicious transit provider, can redirect traffic on their own.

What this means for developers in Brazil

For those who use a Mac in day-to-day development work, the risk isn't abstract. Three concrete scenarios remain exposed while Apple doesn't publish a fix:

• Clones and pulls of repositories via https:// can deliver code chosen by the attacker instead of the project's real code;
• Pushes can be altered in transit, which is especially serious in automated pipelines;
• Credentials, such as personal GitHub tokens used in git clone or pip install from private indexes, can be intercepted if the URL doesn't use a fake username as in the demonstration.

This last point matters for teams that use macOS runners in CI, whether on their own infrastructure or in cloud build services. If the runner is on a network where traffic can be intercepted, any pipeline step that relies on git, curl, or pip to fetch dependencies is exposed to the same supply chain risk that affects an individual developer's machine.

What to do while Apple doesn't fix it

The solution recommended in the report is to manually remove the affected roots from the system's certificate file, following the step-by-step guide published on the site's main page. Since macOS can revert this change in future updates, according to Apple's own guidance cited in the report, it's necessary to repeat the verification tests, and the manual fix, after every system update, until Apple publishes an official fix.

For security and platform teams, the report recommends assessing whether macOS runners are used in CI or in any build step, and treating this as a supply chain risk to be monitored until the final fix. The source code for the verification site is available on GitHub and accepts contributions, under the Apache 2.0 license.