Affected
8 eMudhra intermediate certificates
Reported
October 17, 2026
Status
Revoked and blocked by browsers

One of the secret keys your browser trusted was the number 4

eMudhra, one of the companies your browser trusts to vouch that websites are real, had eight signing keys that were supposed to be numbers about 116 digits long. Every one of them was smaller than 256. Here is how that happened, what it would have let someone do, and what has been fixed.

A P-384 private key is picked at random from 1 up to just below this number, which is 116 digits long:

39402006196394479212279040100143613805079739270465446667946905279627659399113263569398956308152294913554433653942643

The private key of the certificate called EM OV TLS CA - G3C:

4

  1. Guess 1: no match
  2. Guess 2: no match
  3. Guess 3: no match
  4. Guess 4: match

Count up from 1, check each number against the public key in the certificate, and you hit it on the 4th guess.

A real key is a random number up to 116 digits long. This one was 4.

The short version

  • A certificate authority called eMudhra had eight signing keys that were tiny numbers, all below 256. One of them was 4.
  • With any of those keys, someone could have made a fake certificate that browsers would accept for any website.
  • A researcher reported it on October 17, 2026, and browsers started blocking the eight certificates within hours. There is no evidence anyone used them in an attack.
  • Update your browser and your operating system. The risk now is software that never gets those updates.

The video

The story in 1 minute 42 seconds.

How a browser decides to trust a website, why a private key is just a number, and what to update now. Posted October 21, 2026.

Watch on YouTube
See the post on X

What happened

On October 17, 2026, a researcher identified in Mozilla's bug report as Wayne ran a test over certificates from the CCADB, the shared database of certificate authority certificates that browsers trust, and found eight whose private keys anyone could work out. At 18:05 UTC he emailed proof to Apple, Chrome, Microsoft, Mozilla and eMudhra.

The eight are intermediate certificates belonging to eMudhra, a certificate authority based in India. Six were for websites (TLS, the "S" in HTTPS) and two were for signing software (code signing). All eight were created on April 30, 2025, and each one's P-384 private key was a number below 256.

Browsers moved fast. Mozilla received the report at 20:06 UTC, confirmed it, and Firefox started blocking the certificates through OneCRL, its list of certificates to reject, the same day. Mozilla also worked out the keys on its own, without hints, at 21:48 UTC. Chrome, Apple and Microsoft blocked them too. On October 18, eMudhra revoked all eight, giving the reason caCompromise: the certificate authority's own key is no longer secret. Mozilla opened bug 2083449 a few hours later to track the incident in public.

eMudhra says a faulty script made a second set of weaker keys, and staff used those by mistake because the key labels looked alike. That is eMudhra's own account, and Mozilla and Chrome have asked it follow-up questions in the bug. On October 20, Cloudflare said its security review had not found the keys being used against its services.

How it works

When you open your bank's website, your browser has to decide whether it is really talking to your bank. It does that by checking the site's certificate, a small file that says "this public key belongs to this website", signed by a company your device already trusts.

The signing usually happens in a chain. The top of the chain, a root, is built into your device and kept offline. It signs a few intermediate certificates, and those do the day-to-day work of signing website certificates. If every link checks out, you get the padlock. Step through it:

Your browser gets the site's certificate

You visit bank.example (a stand-in for any site). The server sends its certificate, which says which public key belongs to bank.example and is signed by the intermediate EM OV TLS CA - G3C.

Everything hangs on the private key staying secret. And a private key is just a number. For the kind of key eMudhra used, called P-384, the public key is made from the private key by doing a fixed piece of arithmetic on a curve that number of times. Going forward is quick. Going backward, from the public key to the number, is hopeless when the number is picked at random from a range 116 digits long: there are far more possibilities than anyone could ever try.

But public keys are, by design, public: they are printed inside every certificate. If the private key is small, you can simply start at 1, do the arithmetic, compare the result with the public key, and move on to 2. These eight were all below 256, so the search ends almost before it starts.

What we checked ourselves

Wayne found the weak keys and Mozilla confirmed them independently. To check their work, we downloaded the eight certificates, read the public keys out of them, and tried every number from 1 to 255. A short Python script found all eight keys in about 17 milliseconds on a MacBook Pro: 4, 56, 66, 115, 155, 156, 230 and 237. Each of the eight also has a copy cross-signed by another certificate authority, Sectigo, and those copies carry the same keys.

The widget below runs the same search in your browser. It does the real P-384 arithmetic for each guess and compares the answer with the public keys copied from the eight certificates.

Our run, one line per certificate
CertificateKeyTime
EM OV TLS CA - G3C40.07 ms
EM EV TLS CA - G3C560.89 ms
EM OV CS CA - G3B661.03 ms
EM EV TLS CA - G3B1151.98 ms
EM OV TLS CA - G3B1552.88 ms
EM DV TLS CA - G3B1562.52 ms
EM DV TLS CA - G3C2303.61 ms
EM OV CS CA - G3C2373.99 ms
All eightabout 17 ms
Guess 0

Guess times the curve's starting point, first digits not started

Press Start to try every number from 1 to 255.

    Our run: all eight in about 17 milliseconds, in plain Python on a MacBook Pro.

    Reactions

    "Each key should be a 116-digit number, but one was just 4."
    International Cyber Digest, cybersecurity news account @IntCyberDigest, October 20. One of the most shared posts about it, with more than 3 million views by the next day.
    "eMudhra chose private keys between 1 and 256 (the numbers!!) and called it a day."
    Gergely Orosz, author of The Pragmatic Engineer newsletter, @GergelyOrosz, October 21. He pointed out a certificate authority has two jobs: make secure keys and keep them safe.
    "Cloudflare is deploying mitigations and releasing client updates."
    Cloudflare, internet infrastructure company, @Cloudflare, October 20, linking its write-up on the impact and what developers should do.

    The alarmed version went around too: a post from @Pirat_Nation seen nearly half a million times said "half the internet is cooked." The same post noted that Chrome, Firefox, Apple and Microsoft had already blocked the certificates, which is why the realistic risk is much narrower.

    Timeline

    1. eMudhra creates the eight intermediate certificates. Their private keys are all below 256.

    2. Wayne's test run over certificates from the CCADB, the database of trusted certificate authority certificates, finds the broken keys.

    3. He emails proof to Apple, Chrome, Microsoft, Mozilla and eMudhra.

    4. Mozilla receives the report and Firefox starts blocking the certificates through OneCRL. Mozilla recovers the keys on its own at 21:48 UTC.

    5. Chrome's quick-revocation list shows the six website intermediates as revoked.

    6. eMudhra revokes all eight, reason caCompromise. Mozilla opens bug 2083449 at 12:06 UTC.

    7. Cloudflare publishes its guidance and client updates, and says it has seen no active exploitation on its services.

    8. We recover all eight keys from the public certificates to check the findings, and publish our explainer video.

    What it means, and what to do

    The web's padlock rests on secret numbers nobody can guess. One company's mistake put eight of them in reach of anyone with a laptop for about a year and a half. The fix worked quickly for software that updates itself, like browsers. The weak spot now is everything else: servers, gadgets, command line tools and old container images that carry their own copy of the trusted list and never get refreshed.

    If you use a computer or phone

    • Update your browser and restart it.
    • Install your operating system's updates.
    • That's it. There's no sign these keys were used against anyone.

    If you build or run software

    • Update the certificate bundles your systems use (the files listing trusted certificate authorities), then rebuild and redeploy container images.
    • Check what actually verifies certificates in each app. Cloudflare notes it may be an HTTP library, the runtime or the OS rather than your SDK, and a browser or curl test doesn't prove a background service is covered.
    • If something starts failing with certificate errors, don't fix it by turning verification off.

    Questions people are asking

    Was I hacked, or is my data at risk?

    Almost certainly not. There's no evidence anyone used these keys in an attack, and Cloudflare's review found no active exploitation on its services. Up-to-date browsers now reject the eight certificates.

    How can anyone find a private key from public information?

    Normally they can't. The public key is computed from the private key, and reversing that is only practical when the private key is tiny. These were all below 256, so trying every number from 1 upward finds them in milliseconds, as the widget above shows.

    What could someone have done with the keys?

    Any of the six website keys could sign a certificate that browsers would accept for any website, which is what an attacker needs to impersonate a site on a network they control. The two code signing keys could vouch for software.

    How did this happen?

    According to eMudhra, a faulty script created a second set of weaker keys, and staff used them by mistake because the key labels looked alike. Mozilla and Chrome have asked eMudhra follow-up questions in the bug; as of October 23, Mozilla said it had no answers yet.

    If browsers blocked them, why does it still matter?

    Because plenty of software decides trust without a browser: servers calling other servers, smart devices, command line tools and container images built months ago. Those keep trusting the certificates until someone updates their certificate bundle.

    What is eMudhra?

    A certificate authority based in India: one of the companies whose root certificates ship in browsers and operating systems, so the certificates it signs are trusted by default.

    Updates

    1. Mozilla is going further than blocking the eight certificates: it is removing trust in one of eMudhra's root certificates, emSign ECC Root CA - G3, so that software which never checks revocation lists is protected too, and Chrome has committed to a similar path. eMudhra says it has stopped issuing certificates from everything that chains up to that root, and estimates about 30,000 certificates will need to move to another provider. As of October 23, Mozilla said eMudhra had not answered the questions it sent on October 20, and Chrome said delays blamed on "social media scrutiny" were not acceptable. Source: Mozilla bug 2083449.

    2. This page went up. It covers everything known as of October 24, 2026.

    Sources