Eight eMudhra intermediate CAs had keys that were generated incorrectly, and on October 17 the reporter proved it with signatures from every one of them. Firefox and Chrome blocked them the same day. Apple blocked them too, for Safari. On a Mac, git, curl and python3 still trust them, and the macOS 27.2 update on October 26 undid the fix people had applied by hand.
This isn't about Apple being slow. The class is older than Apple: a machine has as many trust stores as it has TLS stacks, and a fix lands in one of them at a time.
The Mechanism
Apple's support notice explains it. Apple says it has been blocking the compromised intermediates since October 19, and that block covers Safari and apps built on Apple's networking framework.
The command-line tools aren't built on those frameworks. curl, git, python3, ruby, perl and openssl check /etc/ssl/cert.pem, a plain bundle of root certificates, and Apple says the file "will be updated in a future macOS update." No date. Until then, a forged certificate chained to one of those intermediates passes in your terminal and fails in your browser.
So the protected half of the machine is the half you browse with. The unprotected half is the one that holds your GitHub token, runs git pull, pip install and curl | sh -- and these days, the half your coding agent lives in. An agent doesn't open Safari. It shells out to the same git and curl you do, with the same credentials.
Check Your Own Machine
The disclosure site runs test hosts signed through the compromised chain. A protected tool refuses them:
&&
A certificate error is the good outcome. If git gets past TLS (an HTTP error or a credential prompt instead of a certificate error) or curl prints curl trusts eMudhra, that tool will accept a forged github.com from anyone sitting on your network path.
And it isn't only the system file. Endor Labs lists the stores that ship their own roots and had to be fixed separately: Python's certifi (2026.10.19), Node (22.23.4, 24.22.1, 26.12.1), Go (1.27.3 and 1.26.10), rustls-webpki (0.103.16), webpki-roots (1.0.10). Every runtime that bundles roots is a trust store, and so is every Docker image and CI runner that bundles that runtime. Patching your laptop says nothing about the image your build pulled last month.
Take GitHub Off the CA Path
For the traffic that matters most, the source code and the token, you don't have to wait for anyone. SSH doesn't use certificate authorities to authenticate GitHub. Your client checks GitHub's host key against known_hosts, and GitHub publishes the fingerprints.
The first line makes git rewrite every https://github.com/ remote to SSH. The second prints the key fingerprints your machine already trusts for github.com. The Ed25519 one should read SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU. If it doesn't match, or there's no entry yet, add the key after checking it against GitHub's page, not by accepting whatever the first connection offers. A compromised CA can't touch that check.
The Tradeoff
SSH covers git and nothing else. Package installs, API calls and every curl in your scripts still go over TLS and still depend on whichever store that tool reads. Some networks block port 22, too (GitHub's ssh.github.com on port 443 is the escape hatch). And the manual fix Apple describes -- removing the affected roots from /etc/ssl/cert.pem -- is real but fragile: 27.2 already reverted it once, and removing roots from a shared file can break other sites that chain to them, which Apple warns about too.
The Hacker News thread spent a lot of time on whether MITM is realistic. On a shared network, ARP spoofing plus an off-the-shelf proxy gets you there, and the attacker only needs it to work once while a token goes by.
Supply chain security fails for lack of agency, not lack of tools. Here the tools exist: a two-line SSH switch, a version bump for certifi and Node, a rebuilt base image. The default is to wait for the vendor's next update. As of October 29, twelve days after the report, that update hasn't shipped. Don't wait for it.