The Private Key Was 4

One of the private keys behind a globally trusted certificate authority was the number 4.

Not a long random number that happens to start with 4. Just 4. Another was 56. Another was 115. Scott Helme pulled all eight out of the public certificates on his laptop in under a second.

That's the eMudhra story. If you only caught the headline, you probably filed it under "browser stuff, already patched." Wrong drawer.

What happened

On October 17 a researcher reported to Mozilla, Google, Apple, Microsoft and eMudhra that the private keys for eight eMudhra intermediate CAs were compromised. Six issue TLS certificates. Two issue code-signing certificates. All were created in April 2025, and every one was cross-signed by Sectigo's AAA Certificate Services root about a month later.

These are P-384 keys. A proper one is a random 384-bit number. eMudhra's were 47 bytes of zeros followed by one byte of something. That's 256 possible values. You don't crack that. You count to it.

eMudhra's account, posted to Mozilla's incident ticket, comes down to a bug in the key ceremony script that created a second, weak key pair on the HSM, two keys with similar names, and a human who picked the wrong one for the CSR. A formal ceremony, a hardware security module, auditors, the whole apparatus of trust. Undone by a naming mix-up.

Helme also noted an AI agent recovered the keys from a single prompt. Keep that in your back pocket the next time someone tells you attackers need to be sophisticated.

The browsers are fine. Mostly.

Credit where it's due. Chrome and Firefox blocked the intermediates on October 17, Apple on the 19th, Microsoft on the 20th, according to Mozilla's Dennis Jackson. Browsers also enforce Certificate Transparency, and no TLS certificate chaining to these CAs ever showed up in the CT logs. So Chrome, Firefox, Edge and Safari users couldn't have been served a forged cert from them.

Cloudflare says it found no active exploitation on its services. Nobody has confirmed an attack in the wild. The sky isn't falling.

But the browser is the one client in your environment with a full-time team keeping its trust current.

Everything else is on its own.

Everything else

Most non-browser TLS clients trust a CA bundle sitting on disk, don't check revocation, and don't check CT. Helme stood up a fake api.stripe.com with a certificate issued through one of the bad intermediates. curl said the cert verified. Python finished the handshake. Node said authorized. Every Linux and Mac box he tried.

Think about what that covers in a normal shop:

• Install scripts and self-updaters pulling code over HTTPS with no signature check, often as root.

• CI/CD runners holding cloud keys, registry tokens and signing keys, running on stale base images.

• Server-to-server API calls with secrets riding in the headers.

• Cameras, printers, firewalls and OT gear with firmware nobody has touched since install day.

Those intermediates don't expire until July 2039. A device with a frozen trust store will accept a forged cert from them for the next thirteen years. Revocation doesn't save it. It never asks.

Then there's code signing. Windows trusts the eMudhra code-signing root directly, so malware signed through either of those two intermediates looks like legitimate signed software to anything that isn't checking revocation. How many of your EDR exclusions and application control rules boil down to "signed by a publisher, let it run"? Go look.

You never chose eMudhra

I'd bet most people reading this had never heard the name before this week. Doesn't matter. Those intermediates were cross-signed by Sectigo's AAA root, which lives in nearly every trust store on the planet. You inherited eMudhra the same way you inherit your vendor's vendor.

That's third-party risk in its purest form. Nobody signed a contract. Nobody sent a questionnaire. Trust got delegated three hops away and you found out from The Register.

Boards don't get told this part. "We use HTTPS" sounds like a control. Underneath, it's a bet that a list of companies you've never vetted will never botch a key ceremony. Most days that bet pays. This week it didn't.

The incident nobody can scope

First question on any incident: when did it start? You scope everything from that answer. Logs, accounts, data, notification clocks.

This one has no answer.

Nobody stole these keys. They were effectively public from the day the certificates existed, so anyone who looked at them since April 2025 could have had them. Helme counts it as a 17-month window. On Mozilla's thread, Ian Carroll put it plainly: the issue can't be contained.

No thief. No timeline. No indicator of compromise for "someone did arithmetic." If an attacker sat on a network path and intercepted a non-browser client with one of these, nothing in your SIEM is going to tell you.

You can't investigate your way out of that. You fix forward and you assume.

What to do this week

Simple for what you can update. Brutal for what you can't.

1. Update every CA bundle you own. OS ca-certificates, Python certifi, Go, Node, Java, Electron apps. Jackson's tracker lists patched versions package by package.

2. Rebuild your containers. A patched base image does nothing for the images already running.

3. Look under the SDK. As Cloudflare points out, an SDK may hand verification off to a runtime or the OS, so updating it may change nothing. Test the actual TLS path each app uses.

4. Don't "fix" cert errors by turning verification off. Once patches land, some things will break. Under pressure, that switch is tempting. It's also exactly what an attacker wants you to flip.

5. Inventory the frozen stuff. Anything that can't take a trust store update needs network controls around it or a replacement date.

6. Check code-signing trust. Hunt for binaries signed by EM OV CS CA G3B or G3C, and review any allowlist that treats "signed" as a stand-in for "safe."

7. MSPs, this is a fleet problem. RMM agents, backup appliances, firewalls across every client. Get it on the board today, before the first client calls you about it.

Bottom line

The key was 4. The fix in browsers took hours. The fix everywhere else will take years, and some of it will never happen.

Trust on the internet is a supply chain, and most of it you've never looked at.

So ask your team one question this week: what in our environment still trusts the internet the way it did in 2025? If nobody can answer, that's your finding.