> Anyone can intercept any HTTPS connection these tools make.
yeah, it's not ideal but the scale of the threat is way overblown tbh. You have to compromise a lot to be able to make a MITM here.
Let's not treat it like PHP2Shell.
Apple’s statement: https://support.apple.com/en-us/149555
Indeed!
On Mac, some command-line tools included with macOS or the Xcode Command Line Tools (including curl, git, python3, ruby, perl, and openssl) check certificates against /etc/ssl/cert.pem. For certificates that chain to a root CA certificate in this file, these tools don't check Apple's block or whether the certificate has been revoked. This file will be updated in a future macOS update. If you use these tools and don't want to wait for the update, you can remove root CA certificates from the file.Why are they not just pushing out the update asap? Unless they're relying on the compromised certs, then it feels it should be incredibly trivial to push
The issue might be Root CA vs intermediates. The root CA that eMudhra rolls upto may be used for other intermediates which were not compromised or revoked. Removing the root CA will mean that these valid certificates no longer work.
This is technically a problem in the CLI - it needs to support revocations properly, not rely on root CA verification only. I’m not sure though whether there’s a standardised mechanism (that Apple supports) for CLIs.
> These steps affect every tool that uses /etc/ssl/cert.pem. Afterward, tools that use only this file might not be able to verify some websites whose certificates chain to these root CA certificates through intermediate CAs that weren't affected.
In pracitce, those root CAs have already been removed in major browsers. If your server uses them, you would likely have needed to migrate to another root already.
Theory: Apple are moving away from user-controllable development tools, towards an AI-hosted application development framework which removes the divide between user and developer, and thus the need for specialized developer tools.
The writing is on the wall for the command line tools.
(We can already see this tooling devaluation happening all over the place. Apple have their variant of this response to the AI tooling-paradigm tsunami…)
That would be a killer move!
Command line tools seem to mesh well with AI. Why would they move away?
Apple seems like an odd company to lump into this group. Any evidence for this? I removed the cert using a CLI command on my Mac.
Some depending on the executable, sometimes it goes through /etc/ssl/cert.pem and sometimes through the Apple framework. This OS is a mess.
Are they just saying "do it yourself"? Can't they just send out an update?
Things like this is why I moved back to Linux after 10 years on macOS.
Not sure what Linux offers that's any better. Didn't Debian ship trivially weak SSH keys for over 2 years because they were trying to silence Valgrind warnings and the random maintainer had no idea what they were doing and there was no oversight or peer review whatsoever?
Running (uname -a) Darwin arrakis.local 27.2.0 Darwin Kernel Version 27.2.0: Wed Oct 14 23:47:07 PDT 2026; root:xnu-13432.41.4~25/RELEASE_ARM64_T8132 arm64, I get the following for both:
curl: (60) SSL certificate OpenSSL verify result: unable to get local issuer certificate (20)
More details here: https://curl.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the webpage mentioned above.Uname is not enough here to identify what has or has not been done to your system to deal with the compromised certificates.
That's disingenuous title
It should be "Apple still ships compromised CA in /etc/". Git is just a victim like every other app using system CA
Is using the system CA not the way to go?
(on linux you always have the update-ca-certificates command that downloads the root certificates from a trusted™ source. but sure, it will not help, if each command starts to bring their own ca package :)
So git on MacOS does trust compromised certs by default? What's wrong with the title then?
It's not factually wrong, but it implies that this is something specific to Git, and possibly might even be interpreted that it is Git's fault.
In reality it's macOS shipping the outdated certificates, and it affects various other command-line tools, like Curl.
Because it isn't got specifically, it is anything that uses the installation of OpenSSL provided by Apple as part of macOS (at least is my understanding).
The problem is that the title implies that it's somehow the fault of the package. That's it, that's the problem; the title is disingenuous in its claim.
"Ten days later, Apple Image Viewer on macOS still trusts the compromised eMudhra certificates" doesn't sound as catchy, but is equally correct because the apps use system CA.
The lede is certainly buried, but calling out an affected development toll on a tech site isn’t a bad call.
Pretty disappointed that Apple hasn’t pushed out an emergency patch to address this, though.
Agreed.
[dead]
This file is used by a bunch of CLIs. Apple is fundamentally dropping the ball here from a security perspective.
> You have to compromise a lot to be able to make a MITM here.
It's trivially easy to mount an ARP spoofing attack. I did that at school two decades ago and on-the-fly rewrote <img src=...> to hardcore porn images for funsies.
mitmproxy [1], a popular toolkit for making that easy, has the option to generate "eMudhra" certificates on the fly now.
It is trivially easy to compromise things, all you need is physical access to the network.
[1] https://news.ycombinator.com/item?id=50189232