eMudhra TLS certificate compromise: browsers are fixed, your estate is not

On Saturday 17 October 2026, a researcher who signs as Wayne emailed Apple, Google, Microsoft, Mozilla and the Indian certificate authority eMudhra a short message, signed eight times. Each signature was made with the private key of one of eMudhra’s intermediate certificate authorities, keys that nobody outside eMudhra should have been able to use. Within two hours of the email, Chrome had blocked the six that could issue website certificates. Within four, Mozilla had recovered the keys itself, without being told how, and confirmed what Wayne had found. Nobody had stolen the keys. They had been generated so badly that anyone holding one of the public certificates could work out the private key in milliseconds.

Six of the eight are TLS certificate authorities that chain to roots trusted by Chrome, Firefox, Safari and Windows. The other two are code-signing authorities trusted by Windows. With one of the TLS keys, anyone could issue a certificate for any website: your bank, your Microsoft 365 sign-in page, your payment provider’s API. Any software that trusted the chain would accept it. The keys had been recoverable since the certificates were created on 30 April 2025.

The browsers are fixed, and most coverage stops there. The harder story is everything else that speaks TLS: Linux servers, container images, Java and Node.js applications, command-line tools, TLS inspection proxies, VPN clients, appliances and embedded devices. Most of them check neither Certificate Transparency nor revocation, so they keep trusting the compromised keys until somebody updates their copy of the trust store. Filippo Valsorda, a cryptography maintainer for the Go programming language, gave Ars Technica his prediction: “This will be a massive cleanup job, bigger than Heartbleed.”

This post sets out the verified timeline, what went wrong inside eMudhra, why browsers were safe when almost nothing else was, and what Australian organisations should do this week. You are very unlikely to be an eMudhra customer, but that is not the question to ask. The question is what in your estate still trusts its keys. Everything here is current as of 21 October 2026 (AEDT). Vendors are shipping fixes daily, and we will update this post as the picture changes.

The short answer

• What happened: eMudhra created eight intermediate CA private keys (six for TLS, two for code signing) whose values were all below 256, when they should have been random 384-bit numbers. Anyone can recover them from the public certificates. The certificates were created on 30 April 2025, and the problem was reported on 17 October 2026.
• Who was protected: Chrome, Firefox, Safari and Edge in their default configurations. They require Certificate Transparency, no certificate issued under these CAs was ever logged, and their pushed revocation lists blocked the CAs on 17 October (Chrome, Firefox), 19 October (Apple) and 20 October (Microsoft).
• Who was not: any software that trusts a root bundle on disk and checks neither Certificate Transparency nor revocation. That covers most servers, scripts, containers, language runtimes, appliances and embedded devices. They stay exposed until their trust store is updated. Nobody can say whether anyone used the keys against them in the more than 17 months the keys were recoverable.
• A root is being removed: Mozilla and Chrome are withdrawing trust from emSign ECC Root CA - G3, the eMudhra root the TLS CAs chain to. eMudhra estimates about 30,000 certificates need to move to another chain, so anything you depend on that uses one will start failing as trust stores update.
• What to do this week: update trust stores everywhere, not just in browsers. Rebuild container images, check Java, Node.js and Windows, get a dated answer from your TLS inspection, VPN and appliance vendors, and test with the two hosts the incident advisory publishes for the purpose.

Verified timeline

All times are UTC. Sources are the public incident record: Mozilla’s incident report, Bugzilla bug 2083449, where Wayne, Mozilla, eMudhra, Sectigo and the Chrome Root Program have all posted; the incident advisory published by Dennis Jackson of Mozilla; and the Mozilla dev-security-policy discussion.

What went wrong inside eMudhra

Eight bits of trust

A P-384 private key is supposed to be a random number between 1 and roughly 2³⁸⁴, a number 116 digits long. The public key is that number multiplied by a fixed point on the curve. Working backwards from the public key is infeasible when the number is random and large, and that is the whole basis of elliptic curve cryptography.

eMudhra’s eight private keys were 4, 56, 66, 115, 155, 156, 230 and 237. Dennis Jackson of Mozilla described them as effectively all zeroes apart from the last byte. Recovering one takes nothing more than computing the first 255 multiples of the curve’s base point and checking which one matches the certificate. As Scott Helme points out, anyone who looked at one of these certificates at any time since April 2025 could have recovered the key in milliseconds on ordinary hardware. Jackson also reported that AI agents he ran locally recovered the keys at the first attempt, from a one-line prompt that framed the task as a capture-the-flag exercise. That is the true measure of the barrier to exploitation: there wasn’t one.

eMudhra’s account

eMudhra’s preliminary explanation, posted to the incident bug on 19 October, is a chain of process failures rather than a single bug. On its account:

1. The keys were generated in Utimaco hardware security modules, which eMudhra says are FIPS 140-2 Level 3 compliant, and eMudhra does not believe the devices were at fault.
2. The ceremony included an approved deviation from its usual procedure, to test wrapping and unwrapping the keys, because these CAs were meant for export to its US and European data centres to meet customers’ data sovereignty needs.
3. A flaw in the ceremony script created a second, weak key pair on the HSM.
4. Because the key labels were similar, the weak keys were used by mistake to build the certificate signing requests. eMudhra’s root signed them, and the same requests went to Sectigo for cross-signing.

eMudhra describes human errors at several steps and says it will re-verify every key ceremony it has run. It says the RSA keys from the same ceremony followed a different path and are not affected, and Mozilla reported that it could not recover the other P-384 keys in the batch, or those of the series that replaced them. eMudhra also says only one of the eight, EM DV TLS CA - G3C, was ever put into production, and that no end-entity certificates were issued from any of them. Those are eMudhra’s statements. The investigation is still open.

The detail worth keeping is the first one. The HSM did its job: it stored a key securely. The key was simply the wrong one. A FIPS certificate tells you a device protects the keys inside it. It does not tell you that the ceremony around it used the key it meant to use. Key ceremonies have scripts, witnesses and auditors precisely to catch this kind of mistake, and this one went unnoticed for more than 17 months.

The warning signs that were missed

Two public signals pointed at this long before October 2026.

The revocation lists that would not verify. In June 2025, Sectigo reported that eMudhra was publishing revocation lists for six new intermediates with invalid signatures. They were the same six TLS intermediates. eMudhra’s first warning from Sectigo had been quarantined by its own mail filters, and its incident report at the time called it an operational error with no certificates affected. In October 2026, eMudhra explained what had actually happened. The revocation lists had been signed with the original, strong keys. Those signatures could not verify, because the certificates had been built on the weak keys. So eMudhra re-signed the lists with the weak keys, and the error went away. Jackson noted in the new bug that it seemed unlikely the same set of intermediates had turned up in two incidents by chance.

The public question nobody could answer. In November 2025, a contributor to badkeys, an open source tool that checks keys against known-weak sets, asked whether elliptic curve keys with tiny private values were worth detecting. Nobody in the discussion knew of such a key in the wild, and the maintainer began looking at better ways to detect them. On 20 October 2026, someone posted the eMudhra advisory to the same thread.

The lesson travels well beyond certificate authorities. When a security control fails verification, the cheapest fix is to make the error disappear. The correct fix is to find out why what you deployed is not what you meant to deploy. eMudhra had that question in front of it in June 2025, and the fix it chose made the weak keys the ones that worked.

Why browsers were safe and almost nothing else was

Default-configured browsers had three layers of protection that most other software lacks.

1. Certificate Transparency. Chrome, Safari, Firefox and Edge accept a publicly trusted certificate only with proof that it has been recorded in a public Certificate Transparency log. The Chrome Root Program says no TLS certificate chaining to the six intermediates was logged before its block, so no forged certificate from them could have been trusted by default in Chrome or other CT-enforcing browsers. Chrome also checked every other CA certificate in its root store and found no other instance of this failure mode.
2. Pushed revocation. Browsers do not rely on the revocation lists CAs publish. They receive compact block lists from their vendors: Chrome’s CRLSets, and Firefox’s OneCRL and CRLite. Chrome’s block landed 100 minutes after the report reached it, and Firefox’s within three hours of Mozilla receiving it, with no update or restart needed.
3. Fast release trains. For users who had switched off the pushed updates, Mozilla shipped new Firefox releases within three days.

Most other TLS clients have none of the three. As Helme puts it, curl, Python, Node.js, Go, Java, git, package managers and the scripts and daemons built on them trust a bundle of root certificates on disk, do not check revocation by default, and do not check Certificate Transparency. That eMudhra and Sectigo revoked the CAs makes no difference to them. Helme demonstrated it by minting a certificate for api.stripe.com with one of the recovered keys. On every Linux and macOS machine he tested, with default settings, curl, Python and Node.js all accepted it.

So the browser fix is not the fix. For everything else, a client stops trusting the compromised CAs only when its trust store changes: the operating system’s certificate bundle, the bundle shipped inside a language package, the one compiled into a binary, or the one in a device’s firmware.

Where your estate stands

Two cautions on workarounds. The advisory publishes commands that distrust the affected roots on macOS, Linux, NetBSD and FreeBSD before vendor packages arrive, and it says they are not recommended for ordinary users. On several distributions they also remove Sectigo’s legacy AAA Certificate Services root, which other software may still depend on. Test them on a small group before rolling them out. And do not respond to a certificate error by turning verification off. Cloudflare’s guidance for its customers makes the same point, and it is the mistake this incident will tempt people into most.

How to check a client

The advisory runs test hosts whose certificates chain through the compromised CAs. From any server, container or CI runner, run:

curl https://dv-g3b-emudhra.we-have-a-problem.com/
curl https://dv-g3b-aaa-emudhra.we-have-a-problem.com/

A certificate error is the result you want: it means the client no longer trusts the compromised CAs. A page that loads means it still does. The advisory also offers a browser check and a download of every test chain, for checking a trust store offline. Run the test from inside your containers and through your proxies, not just from a laptop. And remember that a pass only covers the verifier you tested with, a point Cloudflare’s guidance makes too. A curl test on a host says nothing about a Java, Python or Node.js service on the same host that checks certificates its own way, so test each runtime that makes outbound connections.

The other direction: certificates that will stop working

Removing emSign ECC Root CA - G3 protects everyone who cannot block individual intermediates. It also breaks every legitimate certificate that chains to that root, and Mozilla’s announcement warns that some servers will be unavailable to non-Firefox users until they move to new chains. eMudhra puts the number at about 30,000, most issued through automated ACME renewal, and says it will move subscribers to intermediates under its RSA root, emSign Root CA - G1. Mozilla is not removing that root at this stage, and Chrome says it is reviewing the status of eMudhra’s remaining CA certificates.

If any supplier, partner or SaaS endpoint you connect to uses one of those certificates, connections will start failing as trust stores update, and the failure will look like your problem. Search your outbound proxy or firewall logs for certificate issuers containing “emSign”, and ask the owners of any matching services when they will migrate.

Confirmed, unknown and noise

Confirmed. Eight eMudhra intermediate CA keys were trivially weak from their creation on 30 April 2025. Six are TLS CAs and two are code-signing CAs, and each also has a Sectigo cross-sign, so sixteen certificates share the eight keys. All sixteen are revoked. The major browsers blocked them between 17 and 20 October. Mozilla and Chrome are removing the emSign ECC Root CA - G3 root. Several people have recovered the keys independently, so they should be treated as public.

Unknown.

• Whether anyone used the keys against software that does not check Certificate Transparency. The advisory says plainly that this is not known, and it may never be. A forged certificate used against a server-side client leaves no public trace.
• How Microsoft’s update treats the two code-signing CAs, and how many Windows machines still trust them.
• The exact flaw in eMudhra’s ceremony script. eMudhra says it is still assessing the code.
• What happens to eMudhra’s other roots. Chrome is reviewing them.
• How long the long tail will last. Appliances, VPN clients and embedded devices will be fixed vendor by vendor, and some never will be.

Noise. Some discussion has floated deliberate sabotage. The facts argue against it: a deliberate backdoor would use a key only its creator could recover, not one that anyone with a laptop can find in milliseconds. This looks like an error. That makes it no less serious.

Twenty years of the same lesson

eMudhra is the latest in a long line of trust failures, and the earlier ones predict how this one will play out.

The pattern from Heartbleed and the 2021 root expiry is the one that matters for planning. The browser fix takes hours. The tail takes years, because it runs through every device and image that carries its own copy of the trust list.

What this means for Australian organisations

Australian organisations are exposed here as relying parties, not as customers. We could find no ASD advisory on the incident as of 21 October. It still lands squarely on obligations you already have.

• ASD Essentials and the Essential Eight. ASD published ASD Essentials on 15 October 2026 as an evolution of the Essential Eight, and keeps both on cyber.gov.au during the transition. This incident maps directly onto actions in its enterprise IT chapter: applying patches within risk-based timeframes (PRO-06), using vendor advisories to track supplier and component exposure and acting in proportionate time (PRO-16), keeping current assurance that suppliers meet their commitments (GOV-11), and running only verified, authorised software (PRO-07), which is where the code-signing CAs belong. If you still report against the Essential Eight, the same work sits under patching applications and operating systems, and application control. Either way, watch for one trap: a ca-certificates update is a routine package update, which is exactly why it gets deprioritised. Your vulnerability scanner may not flag a stale bundle either, because the only CVE is for Go’s standard library, and a stale certificate bundle inside a Python application or a container image may not register as a finding at all.
• The ISM and ASD’s key management guidance. The Information Security Manual and ASD’s publication on managing cryptographic keys and secrets both assume you know where your keys and trust anchors are. This incident tests whether you do.
• APRA CPS 234. CPS 234 requires an information security capability commensurate with the threats you face, and holds the board ultimately responsible for it. For most regulated entities this will not be a notifiable incident unless you find evidence of interception, but make that call formally and record the assessment, so the board can see the question was asked and answered.
• APRA CPS 230 and third-party risk. Your material service providers run appliances, gateways and integrations that make TLS connections on your behalf. Their trust stores are your exposure. This is a good, concrete question to put to them under CPS 230, and our third-party risk guide covers how to make that kind of question part of continuous monitoring rather than an annual questionnaire.

The questions your board will ask

Were we exposed? Almost certainly yes, somewhere. The honest answer separates browsers (protected from the start) from everything else (exposed until patched), and gives a date by which the second group will be closed.

Can we prove we weren’t attacked? No, and nobody can. There is no public record of certificates forged for non-browser clients, and most clients keep no log of the certificate chains they accepted. What you can show is when each part of your estate stopped trusting the compromised CAs, tested rather than assumed.

How long did it take us to stop trusting a compromised CA everywhere? This is the question that matters most, and it is the same capability the next few years will demand anyway. Public TLS certificates drop to a 47-day maximum lifetime by March 2029, and the move to post-quantum cryptography means replacing algorithms and trust anchors across the estate. We set out both in our guide to managing cryptography in the post-quantum era and the post-quantum planning timeline. An organisation that can update every trust store in a week has the cryptographic agility those changes need. One that is still finding stale bundles in a month has learned where its inventory is missing.

How we can help

We don’t sell certificates or trust store scanners, and you don’t need either to respond to this. What most organisations lack is an inventory of where TLS is checked and an owner for keeping it current.

• Our security posture assessment is a two-week, fixed-price review against the Essential Eight, CPS 234, ISO 27001 and NIST CSF 2.0, with evidence. It shows where your patching, application control and supplier oversight actually stand, which is exactly where this incident tests you.
• Our fractional CISO gives you a named person accountable to your board, who can brief this incident with the confirmed and unknown split above and own the follow-up.
• For CI/CD runners in particular, our guide to securing CI/CD pipelines in regulated environments covers the controls around the credentials a forged certificate would expose.

A checklist for this week

1. Confirm every managed browser is current, including Firefox ESR 115.43.1 or 153.5.1, and that no policy blocks updates or remote settings.
2. Patch ca-certificates on every Linux host, then restart long-running services.
3. Rebuild and redeploy every container image, including images pinned to a digest.
4. Update language dependencies (certifi, Rust webpki-roots, Composer, Perl Mozilla::CA, castore), rebuild Go binaries with Go 1.27.3 or 1.26.10, and track the Node.js and Bun releases that carry the fix.
5. For every JVM, find which trust store it uses, and remove emSign ECC Root CA - G3 from bundled cacerts files until JDK updates arrive.
6. Check Windows machines receive the updated disallowed certificate list, including machines where automatic trust list updates have been changed and those on disconnected networks.
7. Review application control publisher rules for anything that trusts an eMudhra code-signing CA, and verify Windows now distrusts both code-signing CAs.
8. Ask your TLS inspection, secure web gateway, VPN and appliance vendors, in writing, when their trust stores blocked these CAs.
9. Run the two curl tests from servers, containers, CI runners and through your proxies. A certificate error is a pass.
10. Search outbound logs for services using emSign certificates, and ask their owners when they will migrate.
11. Record your assessment of the incident, including whether it meets any notification threshold, and brief your board.
12. Name an owner for trust stores across the estate, and add them to your cryptographic inventory.

Further reading

Primary sources are linked throughout. Coverage and analysis worth reading alongside them:

• Ars Technica, Dan Goodin: The Internet goes on high alert after discovery of 8 compromised TLS certs
• Mozilla Security Blog: Protecting Firefox users following the compromise of eMudhra intermediate certificates (20 October)
• Cloudflare (Christopher Patton, Bas Westerbaan, Trishna and Jeremy Hartman): 8 eMudhra certificates are compromised. Here’s what you need to know (20 October)
• Scott Helme: Eight Bits of Trust; eMudhra’s CA keys cracked in milliseconds (20 October)
• LWN: eMudhra intermediate CA compromise (20 October)
• The community patch tracker on ifin.network, and the advisory’s source repository, where vendors add fixed versions as they ship

Frequently asked questions

What happened to eMudhra’s certificates?

eMudhra, an Indian certificate authority, generated the private keys for eight of its intermediate CAs with values below 256, instead of random 384-bit numbers. Anyone can recover those keys from the public certificates in milliseconds. Six are TLS CAs trusted by all major browsers and operating systems, and two are code-signing CAs trusted by Windows. The issue was reported on 17 October 2026, and all eight are now revoked and blocked in browsers.

Am I affected if I don’t use eMudhra certificates?

Possibly, yes. The risk is not to eMudhra’s customers but to any software that trusts eMudhra’s roots. Someone holding the keys could issue a certificate for any website, including yours, and software that has not updated its trust store would accept it. That includes many servers, containers, language runtimes, appliances and embedded devices.

Are Chrome, Firefox, Safari and Edge safe?

Yes, in their default configurations. They require Certificate Transparency, and no certificate issued under these CAs was ever logged. They also blocked the CAs through pushed revocation lists between 17 and 20 October 2026. Users behind a TLS inspection proxy depend on the proxy’s trust store instead.

Why doesn’t revocation fix the problem everywhere?

Most software outside browsers does not check revocation by default, and much of what does treats a failed check as a pass. Browsers solve this with lists their vendors push to them, such as CRLSets and OneCRL. Everything else needs an updated trust store, through an operating system package, a language package, a rebuilt binary or new firmware.

How do I check whether a server or container still trusts the compromised CAs?

Run curl against the two test hosts in the incident advisory, dv-g3b-emudhra.we-have-a-problem.com and dv-g3b-aaa-emudhra.we-have-a-problem.com, from inside the system you want to test. A certificate error means the client no longer trusts the compromised CAs. A successful connection means it still does.

Were the keys used in an attack?

There is no public evidence that they were. Browsers could not have been attacked through them, because no certificate under these CAs was logged to Certificate Transparency. For other clients, nobody can say. The keys were recoverable by anyone for more than 17 months, and a forged certificate used against a non-browser client leaves no public trace.

Why is emSign ECC Root CA - G3 being removed?

Mozilla and Chrome are removing the root to protect software that cannot block individual intermediate certificates. Removing the root cuts off every path through it at once. The side effect is that about 30,000 legitimate eMudhra certificates must move to another chain, by eMudhra’s estimate.

Does this affect code signing?

Two of the eight CAs are code-signing CAs trusted by Windows. eMudhra says they never issued certificates, but anyone with the keys could now issue one and sign software that would appear to come from a legitimate publisher. Organisations should verify that Windows distrusts both CAs and that no application control rule trusts them.

Where to start

Start with the curl test from one server, one container and one CI runner. Whatever passes, you have confirmed. Whatever fails is your list for this week. If the exercise shows that nobody owns your trust stores, talk to us about a security posture assessment. If you want a baseline first, the maturity assessment takes ten minutes.