Right, so it's not just git, it's a bunch of system-provided utilities; macOS trusts bad certs, and these utils that trust the OS are affected. I use homebrew for my git and curl but haven't yet checked to confirm whether that matters here. Kind of outrageous that Apple's guidance is to edit the cert chain manually, and to expect that subsequent OS updates may revert your mitigation, reintroducing the vulnerability (as happened at least once so far).

That MacOS hasn't removed from OS-level /etc/ssl seems like a big deal, affecting more than just OS-supplied git. Is /etc/certs not used by most graphical Mac software, I guess? The chaotic state of OS-level cert management, on Linux as well, is pretty dismaying.

If Apple is still trying to brand themselves as security-forward, you'd think removing the revoked CA certs from /etc in a system update would be a pretty easy thing to do?

Here's what apple (themselves) recommends to patch: https://support.apple.com/en-us/149555

Pretty much every developer on mac should probably run their patch.

Apple’s statement: https://support.apple.com/en-us/149555

While there is no proof that anyone knew about these weak keys for the year and a half that they were trusted by virtually everybody, and there's no evidence of MITM attacks happening in the wild because of it, you can imagine the payoff that a three letter agency would have if, for even 10 days, there was an opportunity to harvest credentials from important people in high places.

I have no evidence or proof, but I am convinced this wrap/unwrap key generation debacle was intentional and the weak keys were discovered and kept secret by the agencies or governments and used to exploit their adversaries.

You don't need to perform a traditional MITM attack _if you own the airport_ or you _own the free public wifi_. The traffic can be harvested in clear text and we have to come to terms with the _remote possibility_ that this was going on for over a year and a half. If not that long, then certainly for the past 10 days.

I'm not being sarcastic when I say that Apple should copy Windows Update, I have no idea how they have got this far without a method to add small patches outside monolithic OS updates.

It seems like we've all just... given up on certificate revocation? CRLs and OCSP were designed for exactly this sort of thing, but they both seen to have been abandoned as unworkable with no replacement.

A flat cert.pem file (or similar) can't say "distrust this intermediate".

macOS already has the verifier needed (Security.framework/trustd path that protected Safari). It would be good if MacOS routed CLIs through it.

They just released MacOS 27.2 a few days ago? How and why did they not do a patch at least then?

Delete /etc/ssl/cert.pem and replace it with the one from MacPorts.

    # /usr/bin/curl https://dv-g3b-aaa-noct-emudhra.we-have-a-problem.com/
    Your client successfully connected to the site. That's bad!
    
    # sudo mv /etc/ssl/cert.pem /tmp/
    
    # sudo ln -s /opt/local/libexec/openssl3/etc/openssl/cert.pem /etc/ssl/cert.pem
    
    # /usr/bin/curl https://dv-g3b-aaa-noct-emudhra.we-have-a-problem.com/
    curl: (60) SSL certificate problem: unable to get local issuer certificate
    More details here: https://curl.se/docs/sslcerts.html

> 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.

This should have been a macOS security update on day 0. Dragging their feet over it is sadly typical when it comes to Apple software nowadays.

People use Apple products because they want to delegate all authority over their operating system to a corporation that knows best. If you trust Apple, you should clearly also trust eMudhra.

If you are finding yourself not trusting eMudhra anyway, then you might want to choose an OS that lets any well vetted and capable security researcher in the world contribute to it.

There must be a long list of things that aren’t fully patched for this yet, on laptops, on servers. Think of packages that ship their own trust anchors, isn’t there a rust crate that compiles with some root certs embedded?

On one hand there’s unmaintained packages that won’t update dependencies. On the other hand, fixed dependencies did not necessarily backport to all possible versions in the wild, making update as a fix unviable for those.

Question for people who know about this: why do we have hundreds of root certificate authorities, when a vulnerability on a single one can break encryption?

Wouldn't it make more sense to have 5 or so that can be more closely monitored, so something like the eMudhra certificates would probably be found before the certificates are deployed?

Like many suggested, a proper fix might be harder than simply revoking a bunch of certificate like the blog authored assumed without breaking downstream features and functions in a large ecosystem and security conscious platform like macOS/iOS.

However, there is certainly a chance that Apple team didn't think the impact was that bad given all the other protections in place.

When Steve Jobs was alive, his Apple company email was leaked and published and Apple customers emailed him for features and fixes all the time and he personally responded once a while. Tim Cook did the same a couple times too. Perhaps the blog author should write in to the new CEO John Ternus or SVP of Software Engineering Craig Federighi too to see if they can fix that.

https://www.apple.com/leadership/

Things like this is why I moved back to Linux after 10 years on macOS.

I would not be surprised if what happened here is that Apple had hardware to release this week and needed to get 27.2 out the door with support for them, and it was "too late" to merge in the certificate store changes. Of course, I think most people here would argue that this is completely unacceptable and I would more or less agree with them, but unfortunately Apple has never been capable of validating a release quickly or pushing small patches. They've tried and, well, most of those efforts have not worked at all. I wonder how they will deal with a new full chain targeting their OSes every week or whatever AI is going to do.

Apple can fix this by building curl with SecTrust [1].

[1] https://eissing.org/icing/posts/curl-apple-sectrust/

Can we get a title edit? OP’s title implies this is a Git bug, but the bug applies to half of macOS, including curl, openssl, python, perl, and ruby, and to only the macOS version of Git. The original title is less misleading, but personally I’d have titled it something like “macOS still trusts the compromised eMudhra certificates in git, curl, openssl, python3, perl, ruby, more”.

I'm not that familiar with the MacOSx system, but do they have a "minor" update path that I'm not aware of? It seems that everything is an 8gb update. Is that why this update isn't getting put out?

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.

If you're not already in the habit of contacting your git remotes over ssh, its probably one worth building. This is gonna keep happening.

To get mine to finally update, I had to leave my laptop plugged in for a couple of hours. There’s some trustd process that runs every so often; I couldn’t figure out a way to manually trigger the sync.

Ran security find-certificate -a -c eMudhra /System/Library/Keychains/SystemRootCertificates.keychain on my work laptop out of curiosity and yep, still there :|

looks like people are buying the stocks of the company(EMUDHRA) after the hit they took last week > https://www.google.com/finance/quote/EMUDHRA:NSE?window=1M

It seems like these trusts should all be delegated to the OS unless there's a really specific need.

Don't run important stuff on your consumer devices. Apple is a consumer brand.

/e/OS from 2026.10.21 also seems to be still affected

> https://support.apple.com/en-us/149555

I applied those commands.

Then, last night, I applied the macOS 15.8.2 from Apple.

Voila, the eMudhra certificates were back. :-(

So I re-applied those commands once more.

Come on Apple, you can do better than that!

I have been wondering recently if Apple are bothering to maintain the Unix side of the OS. Seems like they occasionally remove or deprecate stuff but don’t put any serious effort into maintenance.

This is just another one of those smells.

Appreciate the breakdown.

It's totally wild that there isn't an interactive script/check already built to test, detect, and run the solution on all fronts.

Lots of software does. It's been great for MITMing your own devices to find out what they're doing. It doesn't defeat cert pinning though.

Actually, command line tools like git and curl could choose to support Certificate Transparency as browsers do, and the need for piecemeal manual updates could be reduced.

   which git
   /opt/homebrew/bin/git

skill issue tbh.

Why is the cert.pem not generated from the keychain storage? Does someone want to vibe-code a utility to do that? It seems like the better approach (one master read-write storage with replication)

Microsoft had a small golden age with Azure and Windows 10, and now they are going right back into a Vista-era-like rot. Github is down an awful lot. The reliability is worse than the product I work on for work by like 2 orders of magnitude and we have no ops team. It's a joke.

Windows 11 is awful, lots of the fixes and modernization started in windows 10 has totally stalled, leaving users with 5 different places to change a setting instead of the one old place or one new place. Look how many different UI's there are to adjust sound card / sound settings or display settings. It's a complete mess. Their attempts to jump into the AI game have been a complete joke, despite already having integrated Cortana years ago. Putting Cortana on an llm is such an obvious thing to do, and they already did so much work to make that fully integrated into windows and force it on everyone even though it was trash, and now it's still trash and they don't seem to be able to adapt at all.

Now they can't respond to a complete insecurity in one of their major products in weeks? Why do they even validate certs? Why doesn't revocation work in their app? I don't think they can really be trusted at this point.

What would cause this delay from apple? Is there something behind the scenes that can explain it?

The only thing that works is fines.

Doesn’t macOS have a way to generate cert.pem from the keychain?

This file is used by a bunch of CLIs. Apple is fundamentally dropping the ball here from a security perspective.

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

Well, you know, Apple invest so much into development

: - /

its very good

Not really a big deal, the window to do an MITM has passed.

small indie company lmfao

[flagged]

[flagged]

[dead]

[flagged]

[dead]

[dead]

[flagged]

Albeit helpful, the site is kinda cringe. It leaves a bad taste in my mouth knowing that the author is affiliated with Mozilla.

Of course they would throw shades at Apple. That being said the situation isn't ideal and I'm sure Apple would have shipped an update if it were easy and warranted.