Eight Bits of Trust: The Catastrophic Failure of eMudhra's CA Keys

Sponsored by: Report URI — Note that XSS can potentially leverage passkey-authenticated sessions.

By Scott Helme | Security researcher, entrepreneur, and international speaker specializing in web technologies. Date: 20 Oct 2026 | Read Time: ~7 min

Imagine a Certificate Authority (CA) private key. You expect a massive, random number. Instead, one of eMudhra's private keys was simply the number 4.

Not a number starting with 4, nor a long string of digits ending in 4. Just... 4.

I discovered this by recovering the keys from their public certificates using my laptop. The process took less than a single second.

---

🕒 The Timeline of a Collapse

On Saturday, October 17th, a researcher notified eMudhra, as well as Google, Microsoft, Apple, and Mozilla, that eight intermediate certificates had been compromised. The response was swift:

• Saturday Evening: Chrome deployed a CRLSet update to block the certificates.
• A Few Hours Later: Mozilla utilized OneCRL to block them in Firefox.
• Tuesday, Oct 20: Mozilla publicly announced the issue and released an NSS update to strip the eMudhra root. Chrome confirmed the root would be removed in Chrome Root Store v43.

The Scope of the Breach

The affected certificates were all generated in April 2025 and cross-signed by Sectigo's AAA Certificate Services root in May 2025. They consisted of:

1. Six TLS Issuing CAs (covering DV, OV, and EV across two generations).
2. Two Code-Signing CAs.

---

🛠️ The Technical "How"

As Ian Carroll noted in the discussion, these were secure inherently weak single-byte keys. Because they are so small, they are trivial to factor.

The Math of Elliptic Curves

These keys utilize the P-384 curve. In this system, the public key is derived using the following logic:

$\text{Public Key} = d \times G$

Where:

• $G$ is a standardized base point on the curve.
• $d$ is the private key (a scalar).
• $\times$ represents elliptic curve scalar multiplication.

While calculating the public key from $d$ is easy, reversing the process (finding $d$ from the public key) is meant to be computationally impossible—provided that $d$ is a massive number.

The Comparison: Expected vs. Actual

A secure P-384 key should be a random 384-bit integer, offering $2^{384}$ (roughly $10^{115}$) possibilities.

What a key SHOULD look like:

d = 0x48ac06790886c80c48d31691fd4c0fe9ce3207f9807f2fe571d6e4ec426d78644298fc53df2b92566970e757ac998c34

What eMudhra's keys ACTUALLY looked like:

d = 0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004

Because the keys consisted of 47 bytes of zeros followed by a single byte, there were only 256 possible values to check. I simply computed $1 \times G, 2 \times G, 3 \times G \dots$ until the result matched the certificate.

The Recovered Keys

I analyzed 16 certificates (8 keys, each appearing in an eMudhra and a Sectigo issued cert). Every single one was broken instantly.

Interestingly, these certificates passed all structural checks. A public key derived from $d=4$ is a mathematically valid point on the curve.

---

⚠️ Why This Cannot Be "Contained"

Usually, a CA compromise involves a theft—a specific moment when a key was stolen by a bad actor. In this case, the keys were effectively public from the moment of creation.

"Anyone who looked at one of these certificates, at any point since April 2025, could have recovered the key in milliseconds on commodity hardware."

This creates a 17-month window of total vulnerability. While Chrome argues that Certificate Transparency (CT) would have flagged any forged certificates, CT only detects mis-issuance; it doesn't stop it. Furthermore, many clients ignore CT entirely.

---

🚩 Who is Still at Risk?

While modern, updated browsers (Chrome, Firefox, Safari) are likely safe due to CT requirements and rapid revocation, the rest of the ecosystem is exposed.

Most non-browser TLS clients (e.g., curl, Python, Node, Go, Java, git, and various daemons) typically:

1. Trust a local CA bundle.
2. Do not check revocation by default.
3. Do not check Certificate Transparency.

Consequently, the revocation of these intermediates by eMudhra and Sectigo is useless for these clients.

Critical Exposure Points

We must consider everything that relies on a root store update:

• curl | sh Installers: Many tools (like rustup, nvm, or Homebrew) download scripts via HTTPS without signature checks. A forged certificate allows an attacker to execute code as root.
• IoT Firmware: Many devices update via HTTPS without robust validation.
• CI/CD Pipelines: GitHub/GitLab runners and Jenkins containers often use stale base images to fetch dependencies or push artifacts while holding sensitive cloud keys and registry tokens.