CVE-2026-111943: Compromised Intermediate Certificate Authority
nvd.nist.govGentoo 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"
$ curl --url="https://dv-g3b-emudhra.we-have-a-problem.com/"
$ curl --url="https://dv-g3b-aaa-emudhra.we-have-a-problem.com/"
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
I feel like you shouldn’t have to ask for a non-default version of the package at this point.
Worth noting that people on RedHat still haven't received proper updates, only a workaround that disables two Comodo root certificates that were used to sign the emudhra certificates.
https://access.redhat.com/security/vulnerabilities/RHSB-2026... - "Ongoing"
This is not the first that RHEL is comically slow with updates...
We pay good money for their highest support tier and they are almost always the latest to bring a needed update.
Can't exactly remember what it was but it has happened before. It's a shame.
RHEL also got the PHP patches hours after Debian.
I chose AlmaLinux last time I needed to, and it's been a great way to access the ecosystem — I heartily recommend it as a free RHEL! — but these past few days have me looking in envy at Debian. Corporate stability hasn't been what I expected.
Red Hat patching slowness and upgrades from major version to next were reasons I gave up after 16 years using their distributions, including RHEL.
I had to fall back patching, repackaging and maintaining multiple times while waiting sometimes weeks them to issue fixed packages. I don't know what happened to Red Hat over the years, already before IBM purchased them. But they became too slow on this kind of issues.
Debian consistently provided fixes quickly next day at least and I never had any issues upgrades since from 7 to 12, when I retired. Only reason to do complete reinstall was that ext3 and ext4 disk formats had improvements, which made life bit easier with 64bit systems.
ps. No problems from 12 to 13 any more with my own systems at home.
Commercial support in Linux seems to be loosing its advantage over Debian.
Ubuntu (including Ubuntu Pro) still doesn't have a CVE-2026-99999 patch while Debian does have it. For commercial operators a KVM guest escape vulnerability is quite important.
I honestly think you're better off with RHEL. They might have been slow to act in this situation, but do one scan on a Debian vs a RHEL system container image and I'm confident Debian's will show a lot more red than RHEL (even with the fedora)
I remember RHEL being quite slow with copyfail as well. It'd be nice to have some more comprehensive statistics though.
And I don't put a lot of faith in container scans as a metrics. (More properly, I don't have faith in most containers scanners to properly identify package versions and backports.)
I'm sticking with the RHEL ecosystem for now, but it's now more out of inertia than a feeling that I gain much by it being the corporate standard. It's gone from "by choice" to "by habit".
Python users may need to take their own separate steps, see this discussion:
https://discuss.python.org/t/information-for-python-users-re...
This is such a clusterfuck. I use so many containers in my home lab and various local installations and stuff. Honestly, I have no idea what I'm even supposed to do at this point because I'm not a full time developer.
Well, that is what people who have been around the block a few times have been saying about containers since just about forever. "I don't want to be an admin for my n software packages, I'll use containers!" - now you are the admin of n containers, except with worse tools than your distro and no upstream support.
And since before that, when we started turning to additional packages managers installed with package managers. Pip etc. mean that an “apt upgrade” isn’t enough, when it really “should” be (used to be) in a well managed system.
Then we layered _another_ level of package management on top with Flatpak etc.
I don’t think anyone has _really_ been - in practice - able to understand how many versions of Python (or shells or ruby or Perl etc…) are installed on any system for a decade or two now.
[Edit to add: and I forgot entirely about venvs (and other language’s equivalents). We put package managers into packages! Now there can be a different version of every package for every script on your system. In every container. And Python even has more than one venv system to choose from!]
[Yes, I use all these things - it’s so hard _not_ to and still use modern software or participate in modern software development…]
It's funny that no one seems to even consider using the distro package manager when it's time to complain about Python package management again. The deployment environment is usually well-known thus scriptable, and developers can be expected to know how to install packages on their own distros. And, of course, if the package is deployed as part of a distro, everything is taken care of by the distro people.
Flatpak is somewhere in the middle because it can and does centrally update dependencies, though they are packaged in larger boxes and it's tempting to include more exotic stuff in the app package instead of creating and maintaining a separate Flatpak shared with other dependees.
Nobody seriously considers it because usually, especially in enterprise distros, the major versions are years out of date and missing many features. And many smaller packages just won't be available. Even for something as major as Django it just wasn't viable to use the OS package manager when I tried it in the Debian 8 and then 9 days.
Only one company I've worked at maintained their own distro packages for deploying services. That was 13+ years ago. Every company since then had a containerized deployment strategy, some better than others. My most recent employer went through a massive effort to implement "golden base images" and tooling to ensure when the base image is updated all the dependents are rebuilt and redeployed. Most don't do that.
I use some rules and a few generated scripts and have a LLM handle the management of the containers. Security through a ssh gateway, allows them to deploy/remove containers and then the rule is to stay at least two weeks behind on releases, unless the latest release is security related, which it figures out by reading the release notes.
I ran watchtowerr before, but I think this is a smarter way to do it.
One could say comeuppance is a dish best served cold. So cold people don’t even know it’s been served. All the old sys admins remember!
For me, this comment actually bolsters the argument for containers imo. It's a lot easier to rebuild a system image and redeploy it out across a bunch of apps than it is to update a bunch of VMs (maybe ansible/puppet makes it moot). Idk
Python environment was so brittle, that a solution was found: pack dependencies into "envs" of various kinds. Disk space is cheap, after all (ahem). Now it's time to pay the bill for that approach...
Examples of what you can do:
* Take the containers offline for the time being until you know what to do
* If it's important for your that they keep running, still take them offline and put them in a VPN this weekend
* Use renovate in the future to automatically update your containers
don't worry. if you're in this situation with this attitude, you're likely running out of date container base images and whatnot.
i highly suggest you forget about containers, learn about systemd unit file hardening, and then you only have to play sysadmin to your base os and the binary for the program you want to run.
"Hey claude this is the cve I need you to fix [link]"
Takes about 20 seconds. Depending if you need to hit enter.
cool cool cool. Don't understand what you're doing, and keep not understanding what you're doing. the agents are infallible after all, and who cares about properly verifying certs anyway? that's nerd shit.
We're in October 2026. Updating packages is the easiest thing Claude can do. For me, I asked and received:
Node 26.3 → 26.12.1 Homebrew’s CA bundle, certifi and OpenSSL are updated, and so are Python 3.13 and 3.14 (3.13.17 and 3.14.9). uv 0.10.9 → 0.13.5. python.org Python 3.13: pip 26.2.2, installed from PyPI’s wheel with its checksum checked, then certifi 2026.10.19.
It also checked some of the other recent vulnerabilities like LiteLLM (already updated).
Sure, and by outsourcing this simple thing, you're just a little more complacent. Someday, when it does something silly, you won't notice.
It went OK this time. There's no guarantee that it'll go OK every time, for every thing.
All I'm saying is that understanding how to maintain the systems that you are responsible for maintaining is an important thing, and outsourcing that understanding is very dangerous.
Yeah, at some point I gave up and asked AI to do patching for me. It was a good call because it found affected certificates in places where I wouldn't look (e.g. aws-cli or Libre Office).
uv should be your friend.
uv defaults to its own trust store afaik lol
maybe they meant it "should" be your friend but actually isn't in this case :-)
Welcome to corporate
> Failure to do so could result in monster-in-the-middle (MITM) attacks against TLS clients, including python.org and pypi.org .
Monster?
Gender-neutral variant of man-in-the-middle. They should have just used something less controversial like master-in-the-middle.
"master" is less controversial?
No, it's a reference/joke to the old controversy regarding master/slave naming in computer circles. I don't know how far back that controversy goes, I probably heard about it about a decade ago.
https://www.linuxfoundation.org/blog/blog/master-slave-and-t...
I think that was sarcasm
To be fair, a monster is scary so it fits. Malice in the middle perhaps would have been less confusing.
> Gender-neutral variant of man-in-the-middle
Countless and countless, no, millions of male developers felt discriminated against whenever someone called it Man-in-the-middle. This went on unaccounted for for decades! Finally we’re being seen!
Not to mention all the women who were misogynisticly attacked by assuming women can’t be hackers.
Finally justice. It’s very important that we’re getting our priorities right when talking about security vulnerabilities!
> who were misogynisticly attacked by assuming women can’t be hackers
Eve would like to have a word with you. I haven't heard of Heidi before... but she's apparently one of the cast.
https://en.wikipedia.org/wiki/Alice_and_Bob#Cast_of_characte...
As a sentient cephalopod who has enjoyed hacking staff computers when I slip out of my tank at the National Aquarium every night, I can only say it feels good to be seen. We're finally making progress on de-centering hominid perspectives in favor of a more diverse range of natural intelligences!
Madame-in-the-middle
Monkey-in-the-middle would've worked since someone could monkey with your packets and it's already an established name for a children's game
I prefer the chaotic option of MITM-in-the-middle.
(Mallory-in-the-middle is OK too.)
Or, you know, man-in-the-middle because that was already a correct, perfectly clear use of English.
The women developers would like to cede this gender-neutral replacement back to the men, we don't want to be included.
/s
I absolutely love monster-in-the-middle. Big round of applause to whoever thought of that.
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.
> 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.
Reminder: Neither the CVE nor the linked go alert seem to say that you have to recompile and redeploy your application with the new go version in order to take advantage of this change. Just updating the tool chain and go stdlib isn't enough, because this stuff gets baked into the resultant binary. This is unlike, say, python, Ruby, or java where updating the runtime may be sufficient, depending on your development and deployment model.
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.
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.
> 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.
I feel like I'm going crazy, something which happened (checks clock again to be sure) yesterday (actually two days ago I think, so much has happened that it all blurs together) is being considered old news!
I think that's the case since television went widespread? :) On a more serious note, I was worried that SOMETHING ELSE happened, because what a day yesterday, captain.
eMudhra 1FA OTP Login Bypass: https://mastodon.catgirl.cloud/@49016/117475921584308861
It's down for me, are they on PHP? :D
I'd assume hugged to death
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
Yesterday's discussion: https://news.ycombinator.com/item?id=50166579
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.
The death of security by obscurity
Actually, all these problems are all in well known systems, your obscure full of holes system is fine for now.
We just update PHP from 5.6 to 8.5 lolol it's been delayed for years, done in a day with QA...
Yeah, the entire internet is a dark forest now.
What's this link doing here? This page is about the Go update which rejects the bad certificates if they exist in the system trust store
Presumably it's here because people think it's interesting and want to discuss it.
People want to discuss Go'a blackisting of the CA specifically? Is there that much to say? They saw a compromised CA, its removal is being rolled out to OSes but Go added a blacklist itself just in case up-to-date Go is being used on an outdated OS
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.
Oh my God it's literally this XKCD https://xkcd.com/221/
They should have upgraded to 5 (see today's xkcd alt text https://xkcd.com/3314/ )
> Here a CA derived a secret key from the number 4
RFC 1149.5 FTW
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...
That was an enlightening read. I find it incredible that apparently Google themselves don't use the existing corpus of certificates as a test for 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
Create the problem, sell the solution
What are you talking about?
TL;DR
Certificate authority (eMudhra) generated eight of its intermediate signing keys so badly that anyone can recover the private keys from the public certificates. That means anyone can mint a "valid" HTTPS certificate for any site, such as your bank, GitHub, or PyPI, and impersonate it.
Much better explanation here
https://cycle.io/blog/2026-intermediate-ca-compromise
This is the Go version of the initial HN post https://news.ycombinator.com/item?id=50166579
Is there a way to know that a web/https client is susceptible?
As in - could I connect to a site signed with those certificates and see that my browser/client accepted that certificate?
I assume these certificates have been pulled from most browsers - but - an un-updated curl or wget would still accept these, right?
EDIT: found https://emudhra.we-have-a-problem.com/ , scroll down to 'Does your client still trust the compromised intermediates?'
EDIT 2: a few tests you can also run...
and in Python:curl https://dv-g3b-emudhra.we-have-a-problem.com/import urllib.request;print(urllib.request.urlopen("https://dv-g3b-emudhra.we-have-a-problem.com/").read().decode())For desktop/most server software, they usually defer what to trust to the operating system, so if you've updated your OS' cacerts package they would likely have been revoked.
The really fun stuff are stuff like:
1. embedded and IOT stuff that doesn't ever get OS updates or even have an OS. People are using this to MITM stuff like smart TVs and household appliances and then pwn them.
2. In some cases a Linux container is run in a context where the OS is hidden from it (think serverless/container as a service type platforms). It might not have access to the OS trust store and have to fall back on the one built into the stdlib.
Make sure you run the CLI checks too.
I noticed that Firefox didn't show any connections on that page (good) but when I ran the curl command, it did connect (bad) and I had to update my Ubuntu packages manually to resolve.
Well, it's a check of a client, so obviously you have to run the client that you want to check.
In this case, with curl, it's actually a way to check the system root trust store.
Mine hadn't been updated yet. I'm not sure why Firefox was failing the page check but, in some ways, it was a false positive for me.
Browsers also maintain their own CRLs separate from the OS.
What are the options available besides using intermediate signing keys? This seems like a weak link in trusting crypto.
Related (2 days ago): https://news.ycombinator.com/item?id=50160877
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.
My biggest worry now is what's going to happen with the amount of unemployed software developers seeing these vulnerabilities and not making enough money to pay the bills.
Can you expand on why this is your biggest worry?
a rise in criminality is bad for society.
Is there an RSS feed that reports these kinds of vulnerabilities?
It's a bit surprising that this took ~1.5days to end up on HN.
It was here yesterday, this is just another good opportunity to farm some points.
Slackware also updated ca-certificates yesterday (Wed Oct 21 00:53:24 UTC 2026). The curl commands keks24 mentioned fails as expected
https://ftp.osuosl.org/pub/slackware/slackware64-15.0/Change...
To check, from keks24:
% curl --url="https://dv-g3b-emudhra.we-have-a-problem.com/"
% curl --url="https://dv-g3b-aaa-emudhra.we-have-a-problem.com/"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
> edit: forgot I can't use code blocks on HN
You can, two space at the start of each lineI wonder if they made this change with an assumption that the root CAs wouldn't be distrusted later same day, too.
Fix for OSX - put this in ~/.zshrc:
export CURL_CA_BUNDLE="$(brew --prefix)/etc/ca-certificates/cert.pem"
curl https://dv-g3b-emudhra.we-have-a-problem.com/I've had since Debian 8 (2015) few helper scripts to make me remember better how to manage approved CA's. There are three of those, which have been working all Debian versions since 8 to current 13.
# cat /usr/local/sbin/ca-certificates-list-active
# cat /usr/local/sbin/ca-certificates-reconfigure#!/usr/bin/env bash # # BFMI tool to list Debian CA certificates active - mesrik, 2015 # CA_CONFIG=/etc/ca-certificates.conf CA_REPO_DEBIAN=/usr/share/ca-certificates if [ -f $CA_CONFIG ]; then # study any ca-certificates which have been configured active for i in $(egrep -v '^[#!]' /etc/ca-certificates.conf) ; do cert_source=$(dirname $i) cert_file=$(basename $i) openssl x509 -in $CA_REPO_DEBIAN/$cert_source/$cert_file -noout -subject |\ sed 's/^subject=//' done else echo "$(basename $0): Ooops, was not able to access $CA_CONFIG" fi # eof
# cat /usr/local/sbin/ca-certificates-invalidate-all#!/usr/bin/env bash LANG=C dpkg-reconfigure ca-certificates
ps. I did bit of editing, I didn't expect Tab to be ignored when pasting here.#!/usr/bin/env bash # # BFMI tool to invalidate all CA certificates in Debian Jessie - mesrik, 2015 # CA_CONFIG=/etc/ca-certificates.conf prog=$(basename $0) usage="Usage: $prog { -commit }" if [ $# -lt 1 ]; then echo $usage exit 1 fi if [ "$1" = "-commit" ]; then if [ -f $CA_CONFIG ]; then backup_ext=$(date -r $CA_CONFIG +".%FT%T%z") perl -wpi$backup_ext -e 's/^([^!#].*)$/!$1/;' $CA_CONFIG if [ $? -eq 0 ]; then echo "$prog: backup $CA_CONFIG$backup_ext was made." /usr/sbin/update-ca-certificates fi else echo "$prog: Ooops, was not able to access $CA_CONFIG" fi else echo "$prog: Need -commit to actually invalidate all CA's" fi # eof
Literally xkcd random number. https://xkcd.com/221
Cock-up or conspiracy?
Any sufficiently advanced stupidity is indistinguishable from malice.
I have seen way more malice pretending to be just stupid than the actual stupidity