CVE-2026-111943: Compromised Intermediate Certificate Authority
nvd.nist.gov
nvd.nist.gov
# 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://discuss.python.org/t/information-for-python-users-re...
Takes about 20 seconds. Depending if you need to hit enter.
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).
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.
Awwww. It is like talking to a dev in 2010. Ok. So, there are machines now smarter than you. You are the problem. You are the thing that adds errors. "understanding how to maintain" No, that is over. sorry. As a human, you are too slow, too dumb to compete.
When a CVE comes out, the patch needs to be applied across the company in minutes. YOU cannot do this 2010 dev dude. Put down the Puppet files. Let go of the python PR.
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.
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…]
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.
I ran watchtowerr before, but I think this is a smarter way to do it.
* 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
Monster?
https://www.linuxfoundation.org/blog/blog/master-slave-and-t...
(Mallory-in-the-middle is OK too.)
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!
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...
/s
I absolutely love monster-in-the-middle. Big round of applause to whoever thought of that.
https://access.redhat.com/security/vulnerabilities/RHSB-2026... - "Ongoing"
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.
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.)
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 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.
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.
The problem is Golang has it's own trust store. So you don't benefit from OS patching.
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.
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.
> 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!
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
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...
curl https://dv-g3b-emudhra.we-have-a-problem.com/
and in Python: import urllib.request;print(urllib.request.urlopen("https://dv-g3b-emudhra.we-have-a-problem.com/").read().decode())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.
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.
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.
[0]: https://groups.google.com/a/mozilla.org/g/dev-security-polic...
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.
What a weird comparison...
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/" 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/# cat /usr/local/sbin/ca-certificates-list-active
#!/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-reconfigure #!/usr/bin/env bash
LANG=C dpkg-reconfigure ca-certificates
# cat /usr/local/sbin/ca-certificates-invalidate-all #!/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
ps. I did bit of editing, I didn't expect Tab to be ignored when pasting here.Here is the original story: https://news.ycombinator.com/item?id=50166579
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
You can, two space at the start of each line