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/
I think that this isn’t really getting the right attention, about what a massive WTF situation this is…
its a 384 bit certificate and this is the private key
00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
00:00:04that is just fucking NUTS
Phew to think how close it is to my private key
And 8 of them no less. The guess of this being test code leaking into prod is likely, but security focused companies need consequences for stuff like this. That being said:
Looks like consequences to me…
that’s a very long way to spell the random number 4
::4
That kind of removes the bit size and hides it in assumption.
It’s like winning the lottery
Winning the lottery is (ballpark) 1 in 10^9, so generating a key below a million is like winning 11 lotteries in a row, while buying 1 ticket in each.
They wouldn’t know how you’d done it, but I think you’d be arrested, with valid probable cause.
4E:65:76:65:72:20:67:6F:6E:6E:61:20:67:69:76: 65:20:79:6F:75:20:75:70:20:4E:65:76:65:72:20: 67:6F:6E:6E:61:20:6C:65:74:20:79:6F:75:20:64: 6F:77:6Eis much more secure.
LOL, People are never gonna give this up.
I’m too lazy to do the math. Does that translate to the URL?
No, it is a string of text. “Never gonna give you up never gonna let you down”
"Never gonna give you up never gonna let you down "
ROFL, People are never gonna let this down.
I mean, yes, it’s entirely possible and within the realm of probability of getting that as a key. But realistically it’s very, very, fucking unlikely.
Isn’t every key equally unlikely?
Yes, be in is why having 8 of them total in the 2 digit range (I.e only using up to 6 bits of 384-bits) just screams incompetence of a hand generated key.
4, 56, 66, 115, 155, 156, 230, 237.
That’s amazing! I have the same combination on my luggage.
I used to too.
You’ve Skroobed up
Lottery!!
Sarcasm: Did you have the same lock for your underwear too pwr chance? Mine have sprouted legs.
As noted, most browsers have already blocked the intermediate certificates. The exception appears to be Edge running on Windows 10, which at the time this article went live was still connecting to 12 vulnerable hosts.
LOL
Edge on windows 11 also did it. At least as of last night. My debian boxes are up to date and they have been fixed.
Newest release of Firefox Nightly on Android also still seems to connect.
I updated my Firefox today in the afternoon and afterwards it didn’t connect.
I did try with Fennec from F-Droid, which was fine. I updated Nightly just now, and it does still connect.
Edit: Firefox Beta connects to 6/12 on https://emudhra.we-have-a-problem.com/
Edit 2: Regular Firefox connects to 0/12Edit 3: Latest update fixed this in nightly, I haven’t checked beta.
deleted by creator
private keys were … 56
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.
My Firefox mobile got green ✅
Maybe try manually updating through the app store
In app safari on Mlem got all greens.
Mine showed red, but after updating it now shows all green
What’s odd is that I have auto updates disabled for Firefox on my spare phone, and I still show green on everything. I don’t think it’s updated in a couple months now.
Firefox can push certificate revocation updates without having to push a new browser build
There are no entries in the certificate transparency logs for these intermediates in that period, indicating that CT-enforcing clients like Firefox, Chrome, Edge and Safari could not have been attacked.
what version are you on?
That one is on version 154.0, dated August.
Useful link, thanks.
Mobile Waterfox passes.
Interesting. I’m also using Waterfox and getting all red on my end.
Huh. I have version 1.2.8.1.
1.2.9 for me. Seems like I might have to revert to the older one.
is the post body having issues displaying? asking because this is way past the first time this season i’ve seen people not see it
It’s displaying fine for me, I think I was just scrolling quickly on my phone and didn’t notice that the https://emudhra.we-have-a-problem.com link in the body was different from the linked article. I saw a blockquote in the post body, and figured that the URL beneath the quote was a link to the article.
I’m using Firefox and that site says I’m good.
Yep, my Firefox mobile hasn’t updated yet either, gonna see if there’s an update I can grab.
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?
Odd my mobile Brave rejects all.
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
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.
Update mobile Firefox it should be fixed now
Are you using a vpn/tor?
I’m getting “⚠️ Inconclusive (timed out)” on Firefox 👀
Do you mean not connecting to anything? Because that would be the action if you considered this a threat
That’s… what I said?
I do consider this a threat. A root certificate being compromised is a big deal. Your web traffic goes across multiple devices before reaching its intended destination, and if any one of them are compromised they could successfully perform an invisible man in the middle attack of your browser/app keeps trusting those certificates.
Ssl is pretty useful, yeah, but those that were mass unlocked with a gimmick key were already very insecure and at this moment they are revoked. Either way, aren’t you supposed to be locked in now?
That only applies to applications and services that support remote certificate revocation.
Those certificates were still in use until Firefox offered another update this morning, but that’s just the browser. Every company and their little bastard love child wants you to use an app to connect to their services, how many of those apps support automatic certificate revocation?
Any app on your phone that doesn’t is now vulnerable to being compromised invisibly. A successful MITM attack looks like nothing at all. The attacker decrypts the traffic with the compromised certificate’s secret to snoop in on the secrets (like username and password) and re-encrypts it to send it forward so the destination server doesn’t know any different either.
Now that it’s public knowledge, I guarantee someone is trying to capitalize on it right now.
How certain are you that not a single switch between you and your bank’s website is fully secured?
WDYM you’re still using them all?
You don’t have e any green ticks?
Brave Mobile is green ✅
Good thing my private keys are under a rock by my front door
I hear crypto bros swear by birdbaths xd
(I read this post 2 years ago and the “Repeat this process six more times with my six other bird baths” stuck with me xD)
thanks :) need to bookmark some of these mirrors
I use untrackme on mobile, but I don’t have anything of the sort on the desktop.
This plus the php thing and everything I was planning on doing today is out the window 😖
Why, what were you planning on doing that depended on these things?
I was planning on doing other work beside patching servers today.
Oh I get it, duh 😄
What’s the PHP thing?
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
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.
Adversary-in-the-middle = man-in-the-middle?
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.
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
Man is a gender neutral term
Only in some obsolete or deprecated contexts.
Everyone says mankind.
Monster in the middle is my fave
perp-in-the-path
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.
It’s a term for the attack, yes but not for the attacker
Oof. Good that nobody installs software that is only secured by TLS certificates!
I don’t even know what TLS certificates are.
Okay, the other comment was actually pretty funny. But this one’s a serious answer.
Transport Layer Security protocol is a way to share secrets. Basically, it’s the lock on your airport luggage. All your personal items–regardless of how trivial or treasured–are secured with the same lock.
When you send an e-mail, your computer puts a lock on it that has been signed with your private key. It’s sent to a recipient, who can unlock it with their own key. There’s a complicated exchange of keys and ciphers called a ‘handshake’ that happens when a website is loaded on your computer, or an e-mail is received. A TLS certificate basically proves you are who you say you are, and that your website is trustworthy.
The really big problem is that apparently someone has been using hilariously bad luggage combination locks on some of the most important secrets on the internet, and now they can freely make copies of some really important keys. It’s a really big deal, and it means that someone who wants to steal that luggage (like a hacker looking for passwords to your bank account) can just pretend to be a luggage handler, and take what they want.
What other certificates should I check that the software be secured by before installing it?
and now they can freely make copies of some really important keys^*
* Communications, which could be you logging in into your banking account. The attacker would be able to see your banking password, for example. Or it could replace a software update your laptop is receiving with malware. A manipulated WLAN router in a cafe or an airport could do that.
This was the ELI5 version, and admittedly, network security isn’t my strong suit. Thank you for the correction.
Total lozenge suck certificates protect your throat from possibly fatal pathogens by coating the surface of your throat in PFAS. Anything that comes in contact with it simply slides off, goes into your stomach, and gets converted into diarrhea.
Is this the OG poem for your sprig?
Omg!!
Definitely not. This one doesn’t do poetry
That comment above is poetry.
Who?
Sprog.
Who’s sprog?
Lol this guy doesn’t know sprog.
It was a username on another site, a while ago. They wrote in poems. Nice stuff.
Someone has commandeered their name here on the fediverse; or so it seems.
tween that and PHP CVE, everyone is on fire ATM
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.
MITM HTTPS traffic without a key doesn’t really let you do much of anything, especially with stuff like HSTS. You can mess with DNS, but the whole certificate authority thing is meant to make it so you can’t redirect someone’s traffic to a malicious server.
This leaked private key completely destroys that guarantee, making it extremely scary. ~Plus, saved traffic for any site signed by this key which didn’t use PFS will be subject to post-facto decryption.~
edit: I don’t know wtf I was thinking, the decryption thing is nonsense.
I don’t think so about the post-facto decrypt. Keyexchange runs with the certs of the destination server. The cerst affected by the leak are intermediate certs which give trust to a cert chain AFAIK.
You’re absolutely right, I had shit all mixed up in my head. Oops 😅 thank you for the correction.
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?
Most systems trust a number of “root” CAs, including the one that signed the eMudhra certificate. It’s possible LG TVs look specifically for a trusted LG certificate, but it’s also very possible they use the same certificate stores as most major OSes/browsers.
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.
Yup.
These days, a lot of firmware blobs are also signed with the vendor’s key, so you’d still need to get past that hurdle.
Removed by mod
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.
Removed by mod
Something like DANE, maybe? Only the websites actually using the compromised certificates would be compromised.
Conceptually, I get it. Esepecially if you go with the ‘DNS pinning of CA’ to have a ‘belt and suspenders’ approach where two chains of authority must be broken, one of which inherently tied to your name.
Practically speaking, DNSSEC hasn’t managed to get ubiquitous adoption. To the point where browsers started giving up and doing DNS over HTTPS to well known providers instead.
note: I understand none if this
After trying for a bit, I can certainly relate to understanding little of it. It’s not as concretely explained as I would like and sticks to abstract principles. So no idea about the current state of affairs.
This is TLS, not SSL.
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.
On grapheneOS, i just manually disabled the root CA’s in the trusted root store.
These are all android versions on graphene:
*There are now 14 certs
AFFECTED:
Firefox (nightly),Ironfox, andfennec STILL 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.
Tor is fixed as of 15.0.26 (140.17.0esr) (Build #2016191530) Fennec all clearMy IronFox is clear as per https://emudhra.we-have-a-problem.com/
Same here
Fennec f-droid didn’t connect to any on my test.
Tor is compromised? How do I check if my firefox or chrome has been compromised now?
I thought tor was impossible to decrypt for an attacker, but they can see you are using it.
It isn’t that tor is compromised, it’s the tls root CA, which can be used to create certs to look like valid site cert for any site.
Which basically means the internet is compromised until these (and God knows which other root authorities) are blocked and decertified.
Nice, that’s handy
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
deleted by creator
