Ing. Calogero Bono
Cloudflare has published a follow-up analysis of the eight weak cryptographic keys of the Indian certificate authority eMudhra, discovered on October 19, 2026. According to the company, the most critical systems are already protected and no interception of its connections has been found. However, forged certificates appeared within hours, and many browsers, bots and embedded apps still accept the compromised chain. For those who run websites and online services, the risk is not theoretical.
A few terms before we get into the facts. CA (certificate authority) is the body that issues the certificates behind the HTTPS padlock. Intermediate key is the key the CA uses to sign site certificates. CRL is the list of revoked certificates. Certificate Transparency is the public registry of issued certificates, and SCTs are its receipts. SAN and SNI indicate the domain names included in the certificate and the one requested by the client.
What happened with eMudhra's keys?
According to Cloudflare, eMudhra was supposed to choose a 115-digit number to protect its keys and used the number 4. The other seven keys were equally weak, with values such as 56, 66, 115, 155, 156, 230 and 237.
Cloudflare explains that the intermediate keys can be reconstructed almost immediately by anyone, starting from public certificates. Anyone can therefore create certificates for any domain, which a non-updated client without Certificate Transparency checks would accept.
For the company, the case is unprecedented. Incidents such as DigiNotar, TÜRKTRUST and TrustWave had given the power to issue forged certificates to only a few actors.
How did Cloudflare respond?
On October 19 patches began on high-impact systems, starting with the Pingora proxies facing customer servers, which handle most outgoing connections. Within hours they began rejecting the vulnerable keys.
In parallel, an AI-assisted code analysis identified within four hours the other systems that trusted those keys. A ticket was opened for each one. Urgent fixes had to be made immediately, the others by the end of last week. At the time of publication, a few low-impact tickets remain to be closed.
Have the keys already been used to forge certificates?
Yes, according to Cloudflare. Since October 21 a log in Pingora has recorded certificates signed with the weak keys. In about a week it counted around 22,000 handshake attempts. Two thirds were toward test sites, nearly all the rest toward servers that seem to have created a certificate with the weak intermediate on their own. Every handshake with active verification was rejected.
About 160 cases were anomalous, with domain names belonging to other organizations, some linked to consumer IoT devices. Some certificates were valid for over two years, more than a public CA can issue. One dates to October 20 at 18:19 UTC, less than an hour after Mozilla's report was published.
For Cloudflare, however, these look like default server certificates, not interception attempts. The case resembles others in which a vulnerability is probed right away, such as that of Oracle E-Business Suite.
How many visitors are still vulnerable?
Cloudflare cannot test visitors directly without interrupting connections. It therefore added two probes to the verification pages, one with an eMudhra certificate and one as a control. In a week it collected 50 million probes.
The picture it describes is this.
- Modern, updated browsers are mostly protected.
- Bots and old browsers are not.
- Apps with embedded browsers, such as Android WebView, still accept the chain in 30-40% of cases.
- On large networks, more than half of the probes accept the compromised chain.
After some progress over the first weekend, the trend is flat. Traffic is however skewed by unconfirmed bots, and only clients running JavaScript send probes.
Limits to know
eMudhra claims an error in a key generation script, but has not yet shared it. The role of auditors and cross-signers remains unclear, as does why a CRL was signed first with a possibly correct key and then with the weak one. Cloudflare rules out interception only on the basis of indirect signals. A targeted interception cannot be excluded. Visitor data is also skewed by bots.
What changes for those working in digital
If you manage websites, apps or management software, check that servers, libraries and clients reject eMudhra keys. Software that connects to external services also matters, such as mobile apps with WebViews and automated scripts, since these often lag behind. Developers working on macOS should carefully follow the instructions Cloudflare has indicated. If you have hosting with managed security updates, confirm the patch status with your provider. The issue also touches those who use certificates for digital signatures.
Our take
The most alarming fact is not the bug, but how slowly updates are rolling out. A key that anyone can reconstruct is a huge mistake, yet the fact that over half of the probes still accept the chain shows a broader problem – software nobody updates. The case recalls how much cryptographic keys matter, as in the KeyDrift malware on Cisco SD-WAN. A doubt also remains about the oversight system, since audits and cross-signing did not stop anything.
Frequently asked questions
What are eMudhra's weak keys?
They are eight intermediate keys of a CA, generated with small numbers such as 4 or 56. For this reason anyone can reconstruct them from public certificates and sign forged certificates.
Has Cloudflare been compromised?
According to Cloudflare, there is no evidence of interception of its connections. High-priority systems have been updated and only a few low-impact tickets remain open.
What is the risk for a website or an app?
It depends on the client. A non-updated client without Certificate Transparency checks may accept forged certificates for any domain, enabling possible interception.
Which software remains most exposed?
Bots, old browsers and embedded browsers such as Android WebView. In the latter, according to Cloudflare, 30-40% still accept the compromised chain.
What should I do now?
Update your systems and follow the instructions on the site maintained by Dennis Jackson, cited by Cloudflare. If you develop on macOS, prioritize those guidelines.
What to watch in the coming weeks in the eMudhra case
The case is open on two fronts, eMudhra's explanations and the pace of updates. It is worth following both.
- Check whether eMudhra publishes the key generation script and its conclusions on audits and cross-signers.
- Follow updates to the browsers and runtimes used by your apps, especially WebViews.
- Check your server logs for any certificates with domain names that do not match those requested.
