An Indian firm has found itself at the center of a global cybersecurity scare.
On October 17, 2026, a cybersecurity researcher who goes by “Wayne” sent a short email to Mozilla, Google, Apple and Microsoft with a startling claim: the secret cryptographic keys protecting eight digital certificates issued by eMudhra, a Bengaluru-headquartered company that is one of the world’s trusted certificate authorities, had been compromised. Not stolen by hackers in the traditional sense — just generated so badly that anyone could work them out.
Within three hours, Firefox had blocked the affected certificates. Within days, every major browser maker had followed, and two of them took the extraordinary step of ripping out trust in one of eMudhra’s root certificates entirely — something that essentially never happens to a company this size. Here’s what actually happened, and why it matters even if you’ve never heard of eMudhra.
First, what does a “certificate authority” actually do?
Every time your browser shows a little padlock next to a website’s address, it’s relying on a digital certificate. That certificate is essentially a signed guarantee that says “yes, this website really is who it claims to be,” and it’s what makes your bank login, your Gmail, your UPI app and basically every secure connection on the internet trustworthy.
That guarantee has to come from somewhere. It comes from a small club of companies called certificate authorities (CAs), which browsers and operating systems agree to trust by default. eMudhra is one of these companies — it’s India’s largest, and one of only a handful of Indian CAs trusted globally by Chrome, Firefox, Safari and Windows. eMudhra is also listed on the Indian stock markets, and has a market capitalization of over Rs. 4,000 crore.
CAs don’t sign every certificate with one master key. Instead, they use a main “root” key (kept offline and heavily guarded) to sign a smaller number of “intermediate” keys, and it’s those intermediate keys that do the day-to-day work of signing certificates for actual websites. If an intermediate key leaks, whoever has it can mint a certificate for literally any website — your bank’s site, your company’s site, anything — and browsers would show the padlock and trust it completely.
So how did someone “guess” a 116-digit key?
This is the part that makes the incident so unusual. A private key is normally a massive random number — astronomically large, impossible to guess by brute force. But eight of eMudhra’s intermediate keys, created during a single key-generation session back on April 30, 2025, turned out to be nowhere near that random. Instead of a huge random number, each of these keys was effectively just a small counting number, smaller than 256, dressed up to look like a proper key.
That’s the equivalent of a bank setting a 20-digit vault code but accidentally leaving 19 of those digits as zero. Once you know the pattern, cracking it isn’t advanced hacking — a basic script can run through the first 256 possibilities in well under a second. eMudhra later said the problem traced back to a one-off deviation in their key-generation process: they were testing a method to export a set of keys for data centres abroad, a software flaw caused a second, much weaker set of keys to get created by mistake, and — because the internal labels looked similar — those weak keys were the ones that got used and signed, while the proper ones were quietly discarded.
Those flawed keys sat unnoticed in the wild for about 18 months before anyone caught the issue. eMudhra’s hardware itself (HSMs made by Utimaco, independently certified to a high security standard) wasn’t at fault — this was a scripting and process error layered on top of good hardware.
How fast the internet’s immune system kicked in
The response timeline reads almost like a military drill:
- Oct 17, 8:06 pm UTC — Researcher Wayne emails Mozilla, Google (Chrome), Apple and Microsoft, along with eMudhra, proving he could sign messages using the compromised keys.
- 8:08 pm — Mozilla acknowledges the report and starts the process of blocking the certificates in Firefox.
- 9:48 pm — Mozilla independently reconstructs the same private keys on its own, confirming the flaw is real and trivially exploitable.
- 10:59 pm, Oct 17 (within about 3 hours) — Firefox ships an update blocking all eight compromised certificates for its users worldwide.
- Oct 18, 9:38 am UTC — eMudhra formally revokes all eight certificates.
- Oct 18–20 — Apple and Microsoft roll out their own blocks; Sectigo, a US-based CA that had “cross-signed” some of the same certificates (giving them a second valid trust path), revokes those too.
- Oct 20 — After it emerged that several other independent researchers had separately discovered and even published proof of the same weak keys, Mozilla and Chrome took the rarer step of distrusting one of eMudhra’s entire root certificates (emSign ECC Root CA – G3), not just the eight intermediates — a precaution for software that doesn’t check for revoked certificates in real time.
For context on scale: eMudhra says roughly 30,000 live website certificates, most issued through automated systems, now need to be reissued from a different, unaffected root.
Was anyone actually at risk?
Six of the eight compromised certificates could be used to issue website (TLS) certificates — the kind that puts the padlock in your browser — and two could be used to sign software, which is how your computer decides an app or update is safe to install. In theory, anyone who had worked out these keys could have forged a certificate for any website — say, a fake but “verified” version of a bank’s login page — and browsers would have trusted it completely, enabling a man-in-the-middle attack.
The reassuring part: modern browsers like Chrome, Firefox, Edge and Safari also require every public website certificate to be logged in public, auditable “Certificate Transparency” logs, and investigators found no record of these intermediates having issued any fraudulent certificates through that system. So there’s no evidence mainstream browser users were actually attacked.
The less reassuring part: a lot of software in the world — older devices, certain apps, embedded systems, some developer tools and programming-language libraries — does not check Certificate Transparency logs or revocation lists the way browsers do. For that slice of the internet, there’s no way to be fully certain the flaw was never exploited before it was found, which is exactly why regulators and browser makers reacted as aggressively as they did.
What’s being done — and what you should do
If you use an up-to-date browser (Chrome, Firefox, Edge, Safari) on a regular computer or phone, you don’t need to do anything beyond your usual update hygiene — the fix has already been pushed to you automatically through each browser’s revocation system, and Firefox even shipped a special out-of-cycle release on October 20 to make sure the protection was baked in for everyone.
The cleanup is messier below the browser layer. Because so much infrastructure quietly relies on the same list of trusted root certificates — Linux distributions, programming-language ecosystems like Python, Node.js, Go and Rust, cloud platforms, embedded devices — each of those has to ship its own patch to stop trusting the affected eMudhra root. Several of these patches were still rolling out as of October 20-21. If you run servers, developer tooling or infrastructure that pins or bundles its own CA list, it’s worth checking you’re on an updated ca-certificates package.
eMudhra, for its part, says it has stopped issuing any new certificates from the affected root, is re-verifying every key-generation ceremony it has ever conducted, and is migrating its roughly 30,000 affected customers to certificates from its other, unaffected root.
Why this matters beyond cybersecurity circles
eMudhra isn’t a niche player — it’s a publicly listed Indian company (NSE: EMUDHRA), a key provider of the digital signature infrastructure used across Indian banking, government e-governance services and corporate compliance, and one of the relatively few CAs from India trusted by the world’s major browser and OS makers. Having a browser vendor distrust one of your roots entirely, even temporarily, is about as serious as reputational damage gets in this industry — it’s the digital-certificate equivalent of a bank losing its RBI licence for a line of business.
For Indian users and businesses, the practical fallout is limited: the flawed certificates were mostly unused test/export infrastructure rather than certificates powering everyday Indian websites, and the exposure window appears to have been caught before confirmed abuse. But the episode is a reminder of just how much of the internet’s security rests on CAs quietly doing a handful of extremely precise cryptographic steps correctly, every single time — and how one flawed script in a key-generation ceremony, sitting unnoticed for a year and a half, can ripple out into patches for everything from Ubuntu to Python to Electron apps.