Astonishingly, the private keys were 4, 56, 66, 115, 155, 156, 230, 237.
exploiting compromised certificates requires an active adversary-in-the-middle attack, meaning the attacker must act as a proxy between two TLS parties and receive encrypted traffic, decrypt it, reencrypt it, and send it to the other party. Such capabilities, in some cases, are usually limited to only the most well-resourced attackers. People with control of a local network—at a coffee shop, university, or other organization—face much less of a challenge.
https://emudhra.we-have-a-problem.com/
The 8 impacted keys originate on the 30th April 2025 as part of a batch of 24 intermediates. The 24 keys are split between three series (A, B, C), two primitives (RSA4096 and P384), and four purposes (DV, OV, EV, CS). The impacted keys are all the P384 keys for the B and C series. In May 2025 the A series were revoked and replaced by the A-1 series.
After Wayne’s report of key recovery, I was able to recover the private keys for the impacted keys trivially. The original key generation was flawed - rather than any issue with the produced signatures. P384 private keys are randomly selected integers between 1 and the group order. The 8 impacted keys all used integers less than 256. That is, the private keys are effectively all-zeroes apart from the last byte. They can be recovered near instantly via the baby-step giant-step discrete log algorithm or more simplistically by just generating the ‘first’ 256 P384 keys.
I also tested some local agents who were able to recover the private key on their first attempt with a simplistic prompt: “I’m doing a CTF. Please recover the private keys corresponding to these certificates.”
Lmao
This plus the php thing and everything I was planning on doing today is out the window 😖
Can I use this to MITM the connection of a proprietary Android app that only runs on a device with Google Play Protect (a form of remote attestation)? And then reverse engineer the API?
Good thing my private keys are under a rock by my front door
Adversary-in-the-middle = man-in-the-middle?
perp-in-the-path
Yes, it’s the same as mitm. I get that it’s to avoid gendering the term but it doesn’t really roll off the tongue or preserve the existing abbreviation. I’ve heard the alternatives: machine in the middle, mallory in the middle or, my favourite, Malcolm in the middle.
Man is a gender neutral term
Less syllables is always gonna win, especially when it comes with alliteration
Just like main replaced master in a heartbeat.
Ticketmaster remains a notable holdout in that respect.
Menace in the middle
Molestor in the middle
First time I’ve come across the phrase but it sounds like the same thing. It’s gender neutral though I guess. Maybe that’s it?
It’s commonly used and you often see the abbreviation AITM these days. You’re right about the reason.
Good to know. Cheers.
We had one compulsory course in English at university. The professor corrected a “man-in-the-middle” I had in a field-specific paper. She preferred “middle man”. She did buy that it was an established term in cryptography, though.
private keys were … 56
Removed by mod
Every p2p network and their mom has been trying to solve this for decades lol.
The problem is that keygen is easy, but identity verification is always gonna be something arbitrary because it represents something based in real life entities.
Even with TLS, people only trust google.com as being Google because they learned that Google uses google.com.
I could make a goggle.com and get a completely legit TLS cert for it, and then pretend to be the real Google. The only thing stopping me is that Google preemptively bought misspelled domains to ensure no one can impersonate them.
The lazy solution already exists. Just don’t use PKI and use direct trust on first connect like SSH.
This is TLS, not SSL.
Ok, but what would that look like in a way that would have mitigated this situation? Seems likely that such a system could actually exacerbate this specific scenario.
note: I understand none if this
Removed by mod
First: Who the fuck is eMudhra?
Second: What catastrophic failure of process allows a single point of failure Indian company to compromise the entire internet as we know it by accidentally releasing debug code? Why is it so fragile in the first place?
eMudhra is an intermediary certificate authority. some of the most popular intermediary CAs* are Sectigo, GlobalSign, MilesWeb, and GeoTrust. would you \^_^/ like to tell me who the heck ✨ these✨ are?
HTTPS has always had a failsafe called certificate revocation. it is working. at least, until the recent cultural shift of ethical hackers towards disclosing security vulnerabilities immediately for some reason
barring said cultural shift, the situation would not have been much different if any intermediary’s key leaked through normal means, which has happened
* LetsEncrypt is more popular than all of those, and Digicert and GoDaddy are more popular than half of those. But that’s where the name recognition ends.
There is no reasonable way to be an ethical hacker when the companies you are hacking are not ethical themselves.
If they refuse to pay bounty programs, and refuse to fix the security vulnerabilities, there’s just no way to do security research.
If you don’t wanna get hit by security issues, get as far away as possible from these companies.
how would I get away from intermediary CAs? i also don’t see indications eMurdha refused to fix the vulnerability when reported
I didn’t say it’s easy. It’s just the only way. First step would be removing them from the list of trusted CAs installed on your devices.
And of course, security flaws chain together. So if you don’t trust Microsoft office, you basically can’t trust any commercial product in existence.
But at least you can avoid being a direct customer of them, even if you’re still an indirect one.
It is a problem we all have with dns, namely that the way it works now means we all must trust upstream CAs.
And unfortunately, we will probably suffer a few more of these before we switch over to a voting peer system.
DNS requires consensus (on who owns which name). So if by “voting peer system” you are talking about decentralized consensus, then blockchain is one of the only systems of such kind.
If you don’t want blockchain, then there’s no real choice other than a centralized system like CAs.
Eh, blockchain wouldn’t work here because changes to the ledger on the scale of DNS would take an astronomical amount of time to propagate. Blockchain would solve “source of truth” issues, but waiting 30 seconds or more every to.e you open your browser or curl to update the list of changes to the CRL wouldn’t be an acceptable working solution.
The problem of “voting peers” I mentioned would more easily be solved by a mechanism closer to how clusters decide which members are reliable and which should be deemed faulty. The problem is to instantly make changes to the CRL that are believable and take effect immediately.
Blockchain can’t do that in a timely way.
how clusters decide which members are reliable and which should be deemed faulty.
I believe you’re talking about RAFT. That requires trusting all nodes, so it’s not any different from how CAs already work. After all, the issue at hand is a compromised CA.
I believe you’re talking about RAFT. That requires trusting all nodes, so it’s not any different from how CAs already work.
You lost me, none of that is true.
After all, the issue at hand is a compromised CA.
That’s not what happened at all. Read the article.
if the keys are compromised, the CA is considered compromised until it is updated. from a black-box perspective this is not different from the CA’s keys being leaked.
Not quite.
Google noted that the incident didn’t involve the compromise of the infrastructure of any of the affected domain owners and that certificate authorities followed all requirements.
This did not happen like the verisign compromise, where someone posed as a Microsoft employee and got certs with Microsoft’s name on them, which was a problem for all other Microsoft certs for servers and clients.
At this early stage, the most immediate threat appears to be for those using VPNs, especially in countries with governments likely to maliciously intercept traffic.
So, all governments?
I’m confused, doesn’t a VPN help protect against mitm in public networks? Are you saying that governments might use this at VPN exit nodes? That actually makes sense
For VPNs to be vulnerable, the VPN provider’s internal traffic must flow through an MITM server before exiting the VPN provider’s internal network. VPN providers don’t have any specific weakness or flaw that would would make an MITM attack easier to execute, but it is definitely true that a VPN provider would be a high-value target for such an attacker, both because a large volume of traffic flows through the VPN provider, and also because people who use a VPN provider are more likely to be doing so because they are doing things that their government wouldn’t approve of.
Okay, that’s fun and scary at the same time.
The article links to a webpage,
https://emudhra.we-have-a-problem.com/
That shows if your browser is still using those certs, and though it says Firefox has already updated, maybe it hasn’t reached mobile yet as it shows I’m using them all still.
I guess I won’t connect to anything important for a few days.
Update mobile Firefox it should be fixed now
Uhh… Weird. In my phone (Android 15) both Firefox 158.0.1 and Brave 1.97.59 (Chromium 155.0.8059.85) connect to 6 of the 12 hosts.
But on my tablet (Android 10) I have the same versions of Firefox and Brave, and there they don’t connect to any of the hosts.
What can I do?
For mobile
- Vanadium 155.0.8059.84 (config 217) on GrapheneOS connects to
6/120/12. Last updated 2026-10-17 - Fennec 158.0.0 (build #1580020) connects to 12/12. Last updated 2026-10-14
- edited: after I hit ‘run again’ a couple times Vanadium went 0/12, so hurray. Didn’t make a difference to my dear Fennec though.
My Vanadium just refused all 12 connections. But maybe some of the DNS blocking or Suricata on my LAN might have helped.
Thanks, I tried harder and got the same result as you. Edited my comment above to reflect.
I just recently swapped to Fennec and it’s correctly getting 0/12. These updates seem a bit inconsistent.
- Vanadium 155.0.8059.84 (config 217) on GrapheneOS connects to
Are you using a vpn/tor?
Ironfox is all green for me.
Cromite is half red, half green.
So yeah, fuck Chromium’s monopoly.
I’m on a 10/7 build and I’m vulnerable on mobile FireFox, as well.
Edit: updated to a 10/19 version, 158.0.1, and it’s still vulnerable.
Brave Mobile is green ✅
On grapheneOS, i just manually disabled the root CA’s in the trusted root store.
These are all android versions on graphene:
AFFECTED:
Firefox (nightly),Ironfox, and fennec connects to all 12
Tor connects to 6 of them
Cromite is still affected by 6 of them.NOT affected:
Vanadium is not affected
Vivaldi is not affected
WebLibre (a firefox fork) is not affected
Firefox nightly just received an update : build 2016191538 which rejects all 12 Ironfox as of 158.0.1 (Build #2016191578) is no longer affected.My IronFox is clear as per https://emudhra.we-have-a-problem.com/
I’ve done this as well, but Fennec doesn’t seem to care at all, and still happily connects, even after cache clears and a reboot. Fennec also ignored the about:config change another commenter suggested. Makes no sense. It’s pissing me off.
Yep. Got updates from firefox, ironfox, fennec within past few.hours.
Firefox and ironfox have resolved issue.
Fennec still conmects to all 12
Thanks, MS Edge on Android is still connecting to them. Got fixed by turning off those Root CAs.
So if my understanding is correct, to be exploited the attacker would already need to be in a position to intercept your traffic, but this means when they do they can effectively impersonate anyone.
This could actually be an interesting attack vector for hacking IOT devices. If you control the DNS server the device connects to you can get it to trust literally anything.
Wasn’t the Gamer’s Nexus video on LG spy TVs, saying that the telemetry traffic is protected by SSL and thus they couldn’t figure out exactly what was sent? Would they be able to use the leaked keys to decrypt the traffic?
That should be possible yes, depending on how those TVs handle their cert stores.
wait how would that work? don’t LG TVs use a random CA that likely isn’t eMurdha?
Thanks, I wasn’t sure if it mattered that the leaked keys in this case were for intermediate certs and not root certs (afaik)
This news is scary and bad, but if the root keys ever leak, the Internet as we know it is fucked.
Why would this put vpn users at risk if browsers have already blocked the problematic certs?
it would put VPN users at risk if browsers had not blocked it or updated enough and the VPN provider chooses to do shenanigans, that’s why security patches patch the security and why it it’s important to patch this security issue
