Security News The Internet goes on high alert after discovery of 8 eMudhra certificates compromised TLS certs

Brahman

Level 20
Verified
Top Poster
Well-known
Forum Veteran
On October 19, 2026, at approximately 17:00 UTC, Cloudflare became aware that private keys associated with eight eMudhra intermediate certificates were compromised. These certificates were widely trusted by browsers, operating systems, and also within Cloudflare. Because the keys themselves are weak, an attacker can create a forged certificate for any domain and use it to impersonate servers to intercept or modify traffic. This is a serious security incident with implications across the Internet. For reference, here is a link to more information about how SSL certificates work and why they are so critical to the operation of the Internet.
What happened, and how serious is it?
The October 20, 2026 report concerns eight intermediate TLS certificates belonging to Indian certificate authority eMudhra. Their elliptic-curve private keys were generated with catastrophically low entropy, making the keys recoverable by testing very few possibilities. Someone with those keys could create fraudulent certificates for arbitrary websites.

Cloudflare's own incident report confirms that the affected certificates were trusted by browsers, operating systems and Cloudflare infrastructure. Cloudflare says it deployed mitigations and that its security review had not identified active exploitation of the issue on its services.

The risk is real, but it helps to distinguish three things:
  • Certificate compromise: an attacker can impersonate a legitimate website using a forged certificate.
  • Traffic interception: the attacker generally also needs a position from which to intercept or redirect your connection.
  • Device compromise: this does not, by itself, install malware or give someone control of your PC or router.


Screenshot 2026-10-21 085942.png
 
What happened, and how serious is it? (link omitted)


Hi Brahman, the severity framing is sound: this is a critical CA failure, but it is not evidence that everyone’s traffic was intercepted or that devices were compromised. There is one material correction—the incident involved eight intermediate CA certificates, not eight TLS intermediates. Six were TLS intermediates trusted by the major browser root programs; the other two were Microsoft-trusted code-signing intermediates, according to Mozilla’s incident record.

The failure is particularly ugly because nobody needed to steal a key file or break into an HSM. A normal P-384 private scalar should be selected from an enormous range, but each affected scalar was below 256. Anyone could test the first 256 possibilities against the public key and recover the private key almost immediately. Mozilla independently did exactly that. Calling them “3- to 8-bit keys” is slightly imprecise—the certificates still used P-384, but their private keys had no more than eight bits of effective entropy. Cryptographic strength by decorative label only.

A few timeline details also matter:

  • Google received the report on October 17 and blocked the affected public keys in Chrome later that day.
  • Mozilla distributed its OneCRL block by 22:59 UTC on October 17, without requiring a Firefox update or restart. Its account is here.
  • eMudhra revoked the intermediates on October 18.
  • Cloudflare says it became aware on October 19; October 20 was the public-reporting date, not the original discovery date.

There is some reassuring evidence. Google reports that no certificates chaining to the six TLS intermediates appeared in Certificate Transparency logs before its block. Consequently, forged certificates could not have been accepted by Chrome and other clients enforcing CT during that period. That does not establish zero exploitation globally: non-browser software may not enforce CT or promptly process revocation, and code-signing has different controls. Likewise, Cloudflare’s “no active exploitation identified” applies to Cloudflare’s services and review, not every client on the Internet.

Practical action​


  • Ordinary users: update browsers, operating systems and network-facing applications. Restarting Android can trigger the relevant Google Play Services update. There is no reason to scan the PC or change every password solely because this incident occurred.
  • Cloudflare users: use at least the fixed versions shown in the advisory—desktop WARP/1.1.1.1 2026.8.2115.0, Cloudflare One Client 2.5.6 on Android or 1.12.16 on iOS, and cloudflared 2026.10.2. If you do not use those products, there is no need to install them because of this incident.
  • Administrators and developers: prioritize VPN clients, API tools, language runtimes, containers, embedded devices and applications with bundled or custom CA stores. Merely revoking an intermediate is insufficient when a client does not retrieve or enforce revocation data.
  • Website operators: check whether the served chain reaches emSign ECC Root CA - G3. Google plans to remove that root from the Chrome Root Store on October 27, so affected sites should migrate to another trusted hierarchy before then.
  • Never bypass a certificate warning while waiting for an update.

The browser response was fast; the long tail of appliances, old containers and forgotten trust bundles is where this incident will linger.

Sources
 
These issuing CAs were created under eMudhra’s ECC root in a Key Generation Ceremony (KGC) held on April 30, 2025, using FIPS 140-2 Level 3 Hardware Security Modules (HSMs).

A flaw in the KGC caused a wrap/unwrap step to produce a second set of weak keys alongside the original strong keys. The weak keys were the ones published to the browser root stores. eMudhra is working to establish the root cause.

These roots and issuing CAs have gone through independent audits for two years in a row and have been in browser trust lists since mid-2025. Last weekend, an independent researcher found that the weak keys could be reverse-engineered possibly with AI-assisted techniques.

In case you’re coming to this one late, news broke yesterday that private keys the company used to sign certs were beyond weak: one was literally just the number “4,” and several others were short strings of easily guessed two-or-three-digit numbers. It’s easy to deduce the value of those keys, which makes it possible to forge certs and impersonate websites or other resources.

My Note​

“A flaw in the KGC caused a wrap/unwrap step to produce a second set of weak keys alongside the original strong keys.” I hope they come up with a good tale for this one, because it could read as: “It output a bunch of numbers, and we picked whatever without reading the manual.”

“Have gone through independent audits for two years in a row.” This also smells like smoke and mirrors. What were they audited for?

MichaelJacksonPopcornGIF.gif
 
on my main android browser only six are repaired
and well, is an older version since I run it with the bloat disabled by one of morphe repos.
 
but i guess small it counts since these could be blocked at dns level if you really care
data is out there and waiting in standby, Chrome already patched them most likely but who's sane enough to use that sh1t
 

Recently browsing

Members who viewed this thread in the last 5 minutes

Back
Top