A certificate authority's private keys were so weak that one of them was the number 4

Eight intermediates, April 2025 to October 2026, one broken key generator

The disclosure site says eMudhra generated the private keys of eight intermediate CAs incorrectly, so "anyone can recover them from the certificates". On 17 October the reporter signed a test message with each key and sent it to the root programs. Firefox and Chrome blocked the certificates that day, Apple followed on 19 October and Microsoft on 20 October.

Certificate Transparency logs show no certificates issued under these intermediates between April 2025 and October 2026. That means browsers that enforce CT could not have been targeted. Clients that don't enforce it are another story, and nobody knows whether anyone abused the keys.

The key that is literally "4"

eqvinox pointed out that the compromise is less sophisticated than the word suggests:

"The private key for all 8 'compromised' CAs is a single byte… One of the private keys is literally '4'."

The thread then tried it. A commenter who handed the public key to Opus 5.5 as a puzzle says the model wrote a 30-line baby-step giant-step script and returned "4" after two minutes, without web search.

Fixed in hours for some, a "massive problem" for the rest

"We remediated this incident in a couple of hours for Firefox users who were protected automatically without the need for updates… for the rest of the ecosystem, there has been little to no investment in revocation." — a Mozilla engineer working on revocation tooling (OneCRL, CRLite)

Another commenter refused the "uneven" framing:

"The impact was a complete and total potential compromise of literally everyone. Every domain." — a commenter with a long-running HN account

Package maintainers listed on the disclosure site (Ubuntu, Debian, Go, curl, Node.js, certifi and others) are shipping distrust patches. If your service validates certificates outside a browser, check whether your trust store actually checks revocation.