The eMudhra CA leak: is your browser still trusting a broken key?

What happened

On 17 October 2026, a researcher writing under the name "Wayne" emailed Apple, Google, Microsoft and Mozilla with eight private keys. They belonged to intermediate certificate authorities operated by eMudhra, a Bengaluru-based company that sells TLS certificates under the emSign brand and is one of the few Indian CAs whose roots are trusted globally.

An intermediate CA is the layer that actually signs the certificates websites present. Anyone holding its private key can mint a valid certificate for any domain on the internet — a bank, a mail provider, this site — and any client that trusts that CA will accept the forgery without a warning.

The keys had not been stolen. They had been generated badly. A NIST P-384 private key should be a random integer of roughly 116 digits. These were single-byte values instead:

4   56   66   115   155   156   230   237

Scott Helme recovered all eight from the public certificates in under a second. The certificates were created during a key ceremony on 30 April 2025. The flaw survived eighteen months and two independent audits before anyone noticed.

Why this one is worse than a normal breach

A stolen password can be changed. A stolen CA key cannot be "un-guessed". The only fixes are revocation — telling every client to stop trusting the certificate — and removing the root from the trust store. Revocation works only for clients that check it, and removal works only for clients that get the update.

That gap is the whole story. Chrome, Firefox, Safari and Edge check revocation data on their own schedule and were protected within hours. Many other programs have no such channel. They ship a copy of the CA bundle at build time and keep trusting it until someone rebuilds them.

Who is still exposed

Three weeks after the report, the picture is uneven by design:

• Browsers — patched out of band. No restart, no app update. This is the system working as intended.
• Operating systems — patched, but only if automatic updates are on. Offline and managed machines lag.
• curl, Python (certifi), Node.js, Java, Rust — fixed by a package update. Most of them never checked revocation in the first place, so the intermediate itself had to be removed from the bundle.
• Go binaries — the trust store is compiled into the binary. Go 1.27.3 and 1.26.10 reject these chains (CVE-2026-111943), but every affected program must be rebuilt.
• Electron apps — Slack, Discord and similar tools only pick up the fix when they ship a build on a patched Electron release.
• Containers, IoT, embedded devices — the image or the firmware carries its own bundle. Rebuild or reflash, or stay exposed.
• TLS-inspection gateways — a proxy that decrypts traffic validates the site's certificate on your behalf. If it still trusts the compromised intermediates, it will happily pass a forged certificate to every client behind it.

The public checker run by the researcher's project still recorded 277,806 successful connections in a 24-hour window at the time of writing. Most of that traffic is automated scanners and command-line tools, not people — but it shows the shape of the problem. Revocation is a browser feature in practice.

Does your client still trust it?

The test below uses fourteen real endpoints whose certificates are signed by the compromised intermediates. Nothing is simulated. If your client connects, it still trusts a CA whose private key is public knowledge.

How to read the result

• Blocked — the TLS handshake failed. This is the good outcome. Browsers deliberately do not tell the page why a connection failed, so a network fault looks the same as a rejected certificate; that is what the control row is for.
• Connected — this client accepted a certificate signed with a key that anyone can compute. It can be impersonated.
• Cannot tell — the control failed too, so the test says nothing about trust. A captive portal, a DNS filter or an offline connection will do this.

The No Certificate Transparency row deserves its own line. Chrome, Firefox, Safari and Edge require publicly trusted certificates to be logged to Certificate Transparency, so they reject those two hosts even if they still trusted the CA. A client that connects to them both trusts the compromised keys and skips CT — which is exactly the combination that lets a forged certificate pass unnoticed. Most non-browser clients behave this way.

If you are behind a proxy that intercepts TLS, the result describes the proxy's trust store, not your browser's. A "connected" verdict there means every client behind that proxy is exposed until it is updated.

What to do

Everyone

• Update your browser and your operating system. That is most of the fix, and for most people it has already happened automatically.
• Never click through a certificate warning to reach a site. The warning is the protection working.
• On Android, install pending Google Play system updates and reboot. The block arrives through Play services, not through the browser alone.

If you run servers or build software

• Update the ca-certificates package, language runtimes and any bundled CA list. Homebrew, Debian, Ubuntu, RHEL, Alpine and Arch have all shipped the removal.
• Rebuild Go binaries and container images. A patched host does not patch the trust store baked into an image or a static binary.
• Enable revocation checking where you can, and confirm that it fails closed. A checker that fails open is decoration.
• On TLS-inspection gateways, explicitly distrust all sixteen certificates — eight intermediates plus eight Sectigo cross-signs. Blocking only the eMudhra chain leaves the other path open.
• Search proxy, IDS and TLS-inspection logs for chains containing the affected intermediates.

If you use Incog

Incog renders with GeckoView, so it inherits Mozilla's revocation list and its CT enforcement, including the root removal in NSS 3.131.1. The check above is worth running anyway: it tests the whole path — your network, any proxy in front of it, and the device — rather than just the engine.

Sources

• Chrome Root Program — Protecting Chrome and Android users from compromised eMudhra intermediate CA certificates
• we-have-a-problem.com — technical disclosure, test hosts and proof of key control
• Mozilla bug 2083449 — initial incident report
• Mint — CERT-In advisory CIAD-2026-0050 explained
• The Record — eMudhra withdraws from the global certificate business
• Ars Technica — the internet goes on high alert
• Kudelski Security — technical analysis of the key generation flaw