On 17 October a researcher using the name Wayne told Apple, Google, Microsoft, Mozilla and eMudhra that the private keys of 8 of the company's intermediate certificate authorities could be recovered from their public certificates. To prove it, he signed a message with each one and published the proofs.

The keys should have been random numbers roughly 116 digits long. Mozilla's preliminary analysis found that each was a whole number below 256. Scott Helme recovered all eight in under a second: 4, 56, 66, 115, 155, 156, 230 and 237.

How fast the browsers moved

The email went at 18:05 UTC. Chrome had blocked the six website intermediates by 19:45. eMudhra acknowledged the report at about 21:28. Mozilla's block reached ordinary Firefox users by 22:59.

On 18 October eMudhra revoked all eight, citing compromise. Apple blocked on the 19th and Sectigo, which had cross-signed every one of them, revoked its cross-signatures. Microsoft blocked on the 20th, and Mozilla removed the emSign ECC Root CA G3 entirely.

Under five hours from report to the first block is close to the best this system can do, and that part worked.

Where it did not work

Helme tested the thing that does not get a headline: software that is not a browser.

Curl, Python and Node.js accepted a forged certificate with default settings on the Linux and macOS machines he tried. Windows accepted it unless revocation checking was switched on. His conclusion is the sentence to carry away: "the fact that eMudhra and Sectigo have revoked these intermediates doesn't help them at all."

Revocation is a browser feature in practice. Command line tools, language runtimes, build systems, server-to-server calls and embedded devices mostly do not check, and the ones that do often fail open. An attacker needed the public certificate and a few hundred calculations, and could have done it at any point since the keys were made in April 2025.

Node.js shipped a ca-cert update in its October security release naming this compromise, which is the fix reaching one runtime. Every other one is a separate update on a separate schedule.

What eMudhra says, and what does not fit

eMudhra told Mozilla's public bug tracker that the keys came from a single ceremony on 30 April 2025, that a flaw in the ceremony script produced a second, weak set, and that similar labels led to the weak set being used. It cites "human errors in multiple steps of the process", says only one intermediate reached production and none issued certificates, and is moving about 30,000 certificates to its RSA root.

Its stock exchange filing of 21 October blames a wrap and unwrap step, says the global TLS business is about 1% of revenue, and states that the keys could be reverse-engineered "possibly with AI-assisted techniques".

That last phrase does not survive contact with the facts. Trying every whole number below 256 is 256 guesses. No AI is required, and none was used. The Internet Freedom Foundation makes the same point, and adds a sharper one: eMudhra's own revocation lists from May 2025, for these same intermediates, were re-signed with the flawed keys after the first signatures came out invalid.

The Indian regulatory question

CERT-In issued advisory CIAD-2026-0050 on 21 October, describing keys "generated with insufficient cryptographic randomness".

IFF has written to eMudhra, CERT-In and the ministry asking for a dated incident report, an independent audit by a new auditor, and confirmation of when eMudhra reported to CERT-In and the Controller of Certifying Authorities. Its arithmetic on the six-hour reporting rule is worth repeating: six hours from the researcher's email would have ended at 05:35 IST on 18 October.

Readers who followed the SBI filing and the gap between telling a regulator and telling a customer will recognise the shape. The same six-hour rule, the same silence about whether it was met.

What to do

  • Update your operating system and browser trust stores. That is most of the browser-side fix and it has already happened for most people.
  • Update language runtimes and their bundled CA lists. Node.js shipped this in October; check what your Python, Go and Java environments are using.
  • If you operate anything that validates certificates without a browser, turn on revocation checking and confirm it fails closed.
  • If your site chains to the emSign ECC Root CA G3, you needed a new certificate before 27 October, when Chrome stops trusting it.
  • For Indian government and public sector operators, check whether anything you run chains to that root before users find out for you.

What is not established

  • Whether anyone exploited the weak keys between April 2025 and October 2026. Nobody knows, and the Chrome Root Program says no website certificate chaining to the six was logged in Certificate Transparency before its block.
  • How the ceremony script produced weak keys, beyond eMudhra's description.
  • Why independent audits did not catch a private key with the value 4.
  • Whether eMudhra met the six-hour reporting rule. Neither it nor CERT-In has said.
  • Whether the separately licensed Indian hierarchy used the same procedures. eMudhra says it did not.
  • The researcher's identity. Wayne is the name used in the disclosure.

eMudhra's own filings and the Mozilla bug thread were not retrieved directly for this piece; the quotations above are as the Internet Freedom Foundation's account carries them.