If we've got an intermediate CA leak, then that means... we can now mitmproxy game consoles like PS5. Console hackers are going to have a field day with this.
Hell, I'm going to have a field day with this. I've got some old chinese cameras that desperately need pwning.
I have a Eufy C10 for which I've been pondering for months how I can de-cloud it, seeing as there's basically nothing like Valetudo for Eufy vacuums (or at least not for the C10). Maybe now this will be a bit easier.
Huh, it says that Apple devices were patched on the 19th (yesterday) but my iPhone still fails the tests. My Mac is good though, on both Firefox and Safari. Odd.
I’m running iOS 18.7.8 with no updates available, and yet my phone passes the tests. Seems there’s some kind of update mechanism here outside of OS updates, so I can imagine that it happens at a different schedule for different people.
Must be some type of staged rollout. xprotect and softwareupdate both say they are up to date, and I'm still seeing failing tests on that site (on macos GoldenGate, and ostensibly up to date).
There is a known issues with Firefox for Android, as it gets the CRL less reliably. Should also be fixed by force-refreshing the PlayStore to search for a full app updates. We are investigating.
FWIW my Firefox Nightly on Android, with build date 2026-10-20T09:59:29, also fails (i.e. it connects). Seemingly based on the build date it should be up-to-date? Let me know if you want an actual bug report.
I am on Firefox Mobile 158.0.1, with a build date of 2026-10-19T18:58:56, which I just updated through the Play Store and which still connects to the test sites.
Certificate revocation data (OneCRL and CRLite), as well as the add-on blocklist, are updated over the network again. 6.6 froze these at build time, along with everything else. Version 6.7 only syncs the security-relevant collections and stores the rest in offline bundles.
so perhaps if you're not on 6.7.x yet then it's not actually dynamically downloading the crlite data?
Below is the list of certificates in Certificate Transparency issued by the blocked CAs as of this time. They appear to be non-malicious test certificates, and the DNS name in the first certificate indicates who likely discovered the issue.
What's alarming and unprecedented is that yesterday, two Certificate Transparency log implementations were updated to block the logging of certificates issued by the CAs. This likely indicates total private key compromise, and the blocking by CT logs is to prevent the logs from being spammed by forged certificates. However, it also means there will be no place to record forged certificates found in the wild. (These certificates won't validate in CT-enforcing clients since they won't be in CT logs, but could be used to attack non-CT-enforcing clients.)
It seems like there was public knowledge about this since at least October 15th, when an anonymous user commented on ExplainXKCD for comic 221 (the "return 4" random value):
this comic just keeps aging like a fine wine... 19:16, 15 October 2026 (UTC)
there is options to use the OS trust store with rust and I usually go out of my way to ensure that one is used, the built-in one tends to be default more often because "it just works" and lets you build smaller containers.
I am very surprised that this is handled in the standard library of a programming language. I know cert revocation is a mess on the internet, but still, something really bad must have happened if they go down this route.
Since a program using Go is the very definition of programmatic TLS and often would not be in a position to check CT logs or any other protection on the internet, there's really no better way to block a compromised intermediate certificate authority. Previously, you would see root-level certificate authorities removed, and those are removed by whatever manages the root program on the system, typically the operating system. It's not so much that this is in a programming language's standard library as it is that it needs to exist in a TLS stack. It just so happens that, for Go, those are the same.
I think what fs111 is saying is that this seems like the job of operating system vendors and/or their packaging systems, but yea, cert stores are a mess
But that's my point. In a Go program, the operating system cannot distrust an intermediate CA; it can only distrust the root CA by removing it from its root trust store.
That seems like a great way to fragment this even further. Now I have one programming language doing this in its runtime but all others are not. That does not really solve much IMO
The solution for certificate revocation checking in non-browser TLS clients should be upki, but it’s still very new and hasn’t yet found its place as a standard part of the infrastructure.
They added that for this specific incident. This is not an existing facility like Firefox or Chrome have. Also, the CRL for the root lists them as revoked, so I still find this rather surprising that they added this feature over night and cut new releases.
A few of my friends that helped with https://blog.brycekerley.net/2026/03/08/webpki-and-you.html are insinuating that one CA did a very bad thing and none of the normal TLS libraries support revocation of intermediates in a discoverable way. I know that the cert validation code I wrote at a previous job thirteen years ago doesn’t.
nullenvk | 4 hours ago
If we've got an intermediate CA leak, then that means... we can now mitmproxy game consoles like PS5. Console hackers are going to have a field day with this.
Hell, I'm going to have a field day with this. I've got some old chinese cameras that desperately need pwning.
yorickpeterse | an hour ago
I have a Eufy C10 for which I've been pondering for months how I can de-cloud it, seeing as there's basically nothing like Valetudo for Eufy vacuums (or at least not for the C10). Maybe now this will be a bit easier.
[OP] freddyb | 7 hours ago
Test page at https://emudhra.we-have-a-problem.com/
gavinmorrow | 6 hours ago
Huh, it says that Apple devices were patched on the 19th (yesterday) but my iPhone still fails the tests. My Mac is good though, on both Firefox and Safari. Odd.
misty | 4 hours ago
I’m running iOS 18.7.8 with no updates available, and yet my phone passes the tests. Seems there’s some kind of update mechanism here outside of OS updates, so I can imagine that it happens at a different schedule for different people.
ThinkChaos | 3 hours ago
Yes, Background Security Improvements
trousers | 5 hours ago
Must be some type of staged rollout. xprotect and softwareupdate both say they are up to date, and I'm still seeing failing tests on that site (on macos GoldenGate, and ostensibly up to date).
ralfj | 3 hours ago
Strange, my Firefox on Android fails the test (it connects to the site). Does that not use the CRL?
[OP] freddyb | 3 hours ago
There is a known issues with Firefox for Android, as it gets the CRL less reliably. Should also be fixed by force-refreshing the PlayStore to search for a full app updates. We are investigating.
strugee | 2 hours ago
FWIW my Firefox Nightly on Android, with build date
2026-10-20T09:59:29, also fails (i.e. it connects). Seemingly based on the build date it should be up-to-date? Let me know if you want an actual bug report.chc4 | 2 hours ago
I am on Firefox Mobile 158.0.1, with a build date of 2026-10-19T18:58:56, which I just updated through the Play Store and which still connects to the test sites.
UPDATE: Restarting my phone resolved it.
kototama | 6 hours ago
Thanks. Any idea why Waterfox on mobile fails the test?
refi64 | 6 hours ago
The 6.7.0 changelog says
so perhaps if you're not on 6.7.x yet then it's not actually dynamically downloading the crlite data?
[OP] freddyb | 5 hours ago
Dunno. They probably did not keep their Firefox fork up to date?
quasi_qua_quasi | 4 hours ago
https://glauca.space/@q/117474051360413376
This post and one of the replies (haven't verified, etc etc), claims that all the revoked certs have private keys that are < 256.
amycodes | 4 hours ago
https://chaos.social/@fluepke/117474146569586375 verified here
rest of the "keys" are here https://infosec.exchange/@jjtech/117474212820456971
quasi_qua_quasi | 4 hours ago
Wow. I desperately want to know how this happened.
purplesyringa | 3 hours ago
This comment on the bugzilla uncovers a part of the story: https://bugzilla.mozilla.org/show_bug.cgi?id=2083449#c11
markerz | 2 hours ago
To be clear, they’re one byte, with a value of <256.
I thought this meant they used less than 256 bytes, but it’s so much worse.
agwa | 15 hours ago
Below is the list of certificates in Certificate Transparency issued by the blocked CAs as of this time. They appear to be non-malicious test certificates, and the DNS name in the first certificate indicates who likely discovered the issue.
What's alarming and unprecedented is that yesterday, two Certificate Transparency log implementations were updated to block the logging of certificates issued by the CAs. This likely indicates total private key compromise, and the blocking by CT logs is to prevent the logs from being spammed by forged certificates. However, it also means there will be no place to record forged certificates found in the wild. (These certificates won't validate in CT-enforcing clients since they won't be in CT logs, but could be used to attack non-CT-enforcing clients.)
dzwdz | 9 hours ago
Based on @q3k's comment over at the orange site, forging certs seems to be relatively easy:
edit: Allegedly the private key is 4. Like, the number 4.
kevincox | 4 hours ago
Who know XKCD would be a literal prophecy.
xkcd: Random Number
FedericoSchonborn | 4 hours ago
As it kept happening with The Simpsons and happens nowadays with The Onion: reality has become so dumb, satire can't keep up.
DustyFuzzy | 11 hours ago
There's a non-public bugzilla entry for the Mozilla CA Program, which is unusual, so yeah.
lynndotpy | 4 hours ago
It seems like there was public knowledge about this since at least October 15th, when an anonymous user commented on ExplainXKCD for comic 221 (the "return 4" random value):
https://www.explainxkcd.com/wiki/index.php/221:_Random_Number
dzwdz | 3 hours ago
Wow, good find. According to Bugzilla, Mozilla only received a report of this on the 17th, around 49 hours after this comment was posted.
[OP] freddyb | 8 hours ago
TLDR: If you maintain software that does not use the OS certificate store, remove the roots or (if you can) the intermediate CAs.
If you don't, well, happy update day.
jtdowney | 10 hours ago
FWIW, Rust is also doing similar https://github.com/rustls/webpki-roots/pull/133
cultpony | 5 hours ago
there is options to use the OS trust store with rust and I usually go out of my way to ensure that one is used, the built-in one tends to be default more often because "it just works" and lets you build smaller containers.
fs111 | 12 hours ago
I am very surprised that this is handled in the standard library of a programming language. I know cert revocation is a mess on the internet, but still, something really bad must have happened if they go down this route.
jtdowney | 11 hours ago
Since a program using Go is the very definition of programmatic TLS and often would not be in a position to check CT logs or any other protection on the internet, there's really no better way to block a compromised intermediate certificate authority. Previously, you would see root-level certificate authorities removed, and those are removed by whatever manages the root program on the system, typically the operating system. It's not so much that this is in a programming language's standard library as it is that it needs to exist in a TLS stack. It just so happens that, for Go, those are the same.
aae | 11 hours ago
I think what fs111 is saying is that this seems like the job of operating system vendors and/or their packaging systems, but yea, cert stores are a mess
jtdowney | 10 hours ago
But that's my point. In a Go program, the operating system cannot distrust an intermediate CA; it can only distrust the root CA by removing it from its root trust store.
fs111 | 8 hours ago
That seems like a great way to fragment this even further. Now I have one programming language doing this in its runtime but all others are not. That does not really solve much IMO
jtdowney | 7 hours ago
This is definitely a gap in the TLS stack.
fanf | 8 hours ago
The solution for certificate revocation checking in non-browser TLS clients should be upki, but it’s still very new and hasn’t yet found its place as a standard part of the infrastructure.
previously, previously, previously
fs111 | 8 hours ago
They added that for this specific incident. This is not an existing facility like Firefox or Chrome have. Also, the CRL for the root lists them as revoked, so I still find this rather surprising that they added this feature over night and cut new releases.
jtdowney | 7 hours ago
Go doesn't check CRLs by default. There is a request at https://github.com/golang/go/issues/68573. Very few non-browser environments check CRLs by default.
dzwdz | 4 hours ago
Posting this just so it can be merged into the main story. This is the bugzilla issue, which just was made public a few minutes ago.
bryce | 9 hours ago
A few of my friends that helped with https://blog.brycekerley.net/2026/03/08/webpki-and-you.html are insinuating that one CA did a very bad thing and none of the normal TLS libraries support revocation of intermediates in a discoverable way. I know that the cert validation code I wrote at a previous job thirteen years ago doesn’t.
pyfisch | 17 hours ago
Very odd. There appears to be a CVE but basically no information.
"We highly recommend immediately upgrading to this release." https://groups.google.com/g/golang-announce/c/66pojueaQek
[OP] freddyb | 8 hours ago
jtdowney | 8 hours ago
agwa | 15 hours ago