CVE-2026-111943: Compromised Intermediate Certificate Authority

Posted by keks24 2 hours ago

Comments

Comment by keks24 2 hours ago

Gentoo Linux users are adviced to update the package "app-misc/ca-certificates" to version "20260816.3.125" or higher!:

    # emerge --sync
    # emerge --ask --oneshot --verbose ">=app-misc/ca-certificates-20260816.3.125"

To check via "curl":

    $ curl --url="https://dv-g3b-emudhra.we-have-a-problem.com/"
    $ curl --url="https://dv-g3b-aaa-emudhra.we-have-a-problem.com/"

They should return:

    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.

---

* GLSA 202610-01: https://security.gentoo.org/glsa/202610-01

* https://emudhra.we-have-a-problem.com/

Comment by 1 hour ago

Comment by charlieyu1 2 minutes ago

We are in the era of 6 digit CVE now

Comment by darkwater 1 hour ago

This is news for NIST but old news generally speaking, being the eMudhra debacle. Or am I missing something?

Comment by ale42 1 hour ago

It's the Go version of it, I think.

Comment by colinmarc 59 minutes ago

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

Comment by darkwater 57 minutes ago

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.

Comment by asqueella 1 hour ago

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

Comment by philipwhiuk 49 minutes ago

"proactively" doing some work.

The problem is Golang has it's own trust store. So you don't benefit from OS patching.

Comment by sspiff 33 minutes ago

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.

Comment by imeron 2 hours ago

It's down for me, are they on PHP? :D

Comment by keks24 2 hours ago

Try this: https://www.cve.org/CVERecord?id=CVE-2026-111943

Comment by tom1337 2 hours ago

I'd assume hugged to death

Comment by ColinWright 2 hours ago

Up for me, but slow to load.

Comment by galadran 1 hour ago

https://emudhra.we-have-a-problem.com/

Comment by zkmon 1 hour ago

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.

Comment by cedilla 1 hour ago

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.

Comment by jkahrs595 8 minutes ago

> Here a CA derived a secret key from the number 4

https://xkcd.com/221/

Comment by wiredfool 39 minutes ago

Nor small composites, apparently.

Comment by colinmarc 1 hour ago

The eMudhra CA compromises had nothing to do with LLMs? But I love the vibes.

Comment by prodigycorp 36 minutes ago

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.

Comment by palata 41 minutes ago

> It's like the fish in a pool creating a shark

What a weird comparison...

Comment by RazorX 1 hour ago

This is basically the whole idea of the novel War with the Newts

Comment by alt227 1 hour ago

Im guessing this only affects Go? But I am guessing that from the nist page as none of the headlines mention it at all.

Comment by grey-area 47 minutes ago

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

Comment by alt227 24 minutes ago

Thanks for clarifying

Comment by dathinab 1 hour ago

It's a bit surprising that this took ~1.5days to end up on HN.

Comment by EwanToo 1 hour ago

It didn't

https://news.ycombinator.com/item?id=50166579

Comment by vultour 1 hour ago

It was here yesterday, this is just another good opportunity to farm some points.

Comment by contingencies 29 minutes ago

Fix for OSX - put this in ~/.zshrc:

  export CURL_CA_BUNDLE="$(brew --prefix)/etc/ca-certificates/cert.pem"

To verify, log in to a new shell and run

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

Comment by colinmarc 1 hour ago

TL;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

Comment by t_mahmood 1 hour ago

> edit: forgot I can't use code blocks on HN

  You can, two space at the start of each line

Comment by fabioborellini 1 hour ago

I wonder if they made this change with an assumption that the root CAs wouldn't be distrusted later same day, too.