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.
Go is not vulnerable in the same way software using webpki is, because it generally uses the system trust store. However, this change is about golang proactively blocking the certs, so that even if your OS doesn't update, it still won't trust them.
That's not the case, Go uses the system store with an additional revoke/deny list in crypto/x509 because it allows updating a deployed application on an out of date or slow moving platform or OS.
This CVE is literally just "versions of the Go deny list don't contain the eMuhdra revokation yet". Older versions of Go will still deny certs signed through the compromised certificate if the system store already has the update.
A lot of software is going to be forced to update or retire soon, all unpatched software should be retired off the internet immediately because AI agents are in waiting.
Great. The technology has progressed enough to kill the existing technologies. It's like the fish in a pool creating a shark that eats away all the fish while the fish proudly announce that their great creation (shark) as the frontier progress for their fish race.
Agents have dramatically increased the ability to poke at every single surface out there. I would be surprised if the researcher who found this wasn't assisted by a llm.
The researcher in question has publicly stated[0] that he wanted to try Google's paranoid_crypto tool[1], so he ran it on some roots as a quick proof-of-concept, and the first thing that happened was that it detected these intermediates. He also states he's been running a lot of certificate linters so this was just the next logical step I guess.
No it affects everybody, but most browsers/OSs etc have updated already. This is just a workaround Go put in case the underlying OS has not been updated. Not sure why this link is on the front page as it duplicates previous posts and confuses people, I think it should be merged.
In other words, that software bundled the compromised certs into the binary, so upgrading it is the only way to remove them.
This is about Go proactively blocking intermediates. Which shouldn't strictly be necessary as long as your OS has removed or distrusted the CAs (on my laptop, macOS has done that, although it seems like it did so in a way not all tools have access to; for example, rustls-platform-verifier respects it, but rustls-webpki still loads the bad CAs from the system trust store).
At this point, extrapolating from the speed of AI progress we're seeing, can we expect to see 10x as many reports like this in a single day before the end of the year?
Gentoo Linux users are adviced to update the package "app-misc/ca-certificates" to version "20260816.3.125" or higher!:
To check via "curl": They should return: ---* GLSA 202610-01: https://security.gentoo.org/glsa/202610-01
* https://emudhra.we-have-a-problem.com/
This is news for NIST but old news generally speaking, being the eMudhra debacle. Or am I missing something?
It's the Go version of it, I think.
Go is not vulnerable in the same way software using webpki is, because it generally uses the system trust store. However, this change is about golang proactively blocking the certs, so that even if your OS doesn't update, it still won't trust them.
https://github.com/golang/go/issues/82345
But the Go version is as well old news, actually it was one of the first stories about eMudhra appearing on the HN homepage yesterday.
This seems to be about ‘go’ proactively blocking emudhra certs even though the system trust store is out of date? https://pkg.go.dev/vuln/GO-2026-6809
"proactively" doing some work.
The problem is Golang has it's own trust store. So you don't benefit from OS patching.
That's not the case, Go uses the system store with an additional revoke/deny list in crypto/x509 because it allows updating a deployed application on an out of date or slow moving platform or OS.
This CVE is literally just "versions of the Go deny list don't contain the eMuhdra revokation yet". Older versions of Go will still deny certs signed through the compromised certificate if the system store already has the update.
It's an or situation, not and.
Python users may need to take their own separate steps, see this discussion:
https://discuss.python.org/t/information-for-python-users-re...
Yesterday's discussion: https://news.ycombinator.com/item?id=50166579
Related (2 days ago): https://news.ycombinator.com/item?id=50160877
https://emudhra.we-have-a-problem.com/
It's down for me, are they on PHP? :D
I'd assume hugged to death
Try this: https://www.cve.org/CVERecord?id=CVE-2026-111943
Up for me, but slow to load.
it's been slow for me since yesterday, i chalked it up to PHP CVEs + throttling a VPN user
We are in the era of 6 digit CVE now
A lot of software is going to be forced to update or retire soon, all unpatched software should be retired off the internet immediately because AI agents are in waiting.
Great. The technology has progressed enough to kill the existing technologies. It's like the fish in a pool creating a shark that eats away all the fish while the fish proudly announce that their great creation (shark) as the frontier progress for their fish race.
Here a CA derived a secret key from the number 4.
If you think "that's weird to see such a small number in key generation" than you're one step ahead of whoever generated that key.
Unfortunately, unlike with RSA, small primes are not apparent in elliptic cryptography.
> Here a CA derived a secret key from the number 4
https://xkcd.com/221/
Oh my God it's literally this XKCD https://xkcd.com/221/
Nor small composites, apparently.
The eMudhra CA compromises had nothing to do with LLMs? But I love the vibes.
Agents have dramatically increased the ability to poke at every single surface out there. I would be surprised if the researcher who found this wasn't assisted by a llm.
The researcher in question has publicly stated[0] that he wanted to try Google's paranoid_crypto tool[1], so he ran it on some roots as a quick proof-of-concept, and the first thing that happened was that it detected these intermediates. He also states he's been running a lot of certificate linters so this was just the next logical step I guess.
[0]: https://groups.google.com/a/mozilla.org/g/dev-security-polic...
[1]: https://github.com/google/paranoid_crypto
> It's like the fish in a pool creating a shark
What a weird comparison...
This is basically the whole idea of the novel War with the Newts
Im guessing this only affects Go? But I am guessing that from the nist page as none of the headlines mention it at all.
No it affects everybody, but most browsers/OSs etc have updated already. This is just a workaround Go put in case the underlying OS has not been updated. Not sure why this link is on the front page as it duplicates previous posts and confuses people, I think it should be merged.
Here is the original story: https://news.ycombinator.com/item?id=50166579
Thanks for clarifying
As of last night the AWS Corretto JDK still ships a trust store that trusts those compromised certs, too.
It's a bit surprising that this took ~1.5days to end up on HN.
It didn't
https://news.ycombinator.com/item?id=50166579
It was here yesterday, this is just another good opportunity to farm some points.
Fix for OSX - put this in ~/.zshrc:
To verify, log in to a new shell and runTL;DR:
The very urgent uv/certifi/etc releases (and yet-to-be-done bun release) are about removing the compromised CAs as described here:
https://emudhra.we-have-a-problem.com/
In other words, that software bundled the compromised certs into the binary, so upgrading it is the only way to remove them.
This is about Go proactively blocking intermediates. Which shouldn't strictly be necessary as long as your OS has removed or distrusted the CAs (on my laptop, macOS has done that, although it seems like it did so in a way not all tools have access to; for example, rustls-platform-verifier respects it, but rustls-webpki still loads the bad CAs from the system trust store).
edit: forgot I can't use code blocks on HN
> edit: forgot I can't use code blocks on HN
I wonder if they made this change with an assumption that the root CAs wouldn't be distrusted later same day, too.
Cock-up or conspiracy?
Any sufficiently advanced stupidity is indistinguishable from malice.
At this point, extrapolating from the speed of AI progress we're seeing, can we expect to see 10x as many reports like this in a single day before the end of the year?