A certificate authority shipped the XKCD punchline
A striking disclosure from security researcher "Wayne" on October 17th revealed a profound failure in public key infrastructure: eight eMudhra intermediate certificates, including TLS and code-signing authorities, were compromised. The underlying private keys for these certificates, trusted by major browsers and operating systems for 17 months, were trivially small integers—one literally the number 4.
These keys relied on the P-384 elliptic curve, which typically requires a private scalar (d) to be a large, unpredictable 384-bit number, offering roughly $10^{115}$ possibilities. Instead, eMudhra's compromised keys featured 47 leading zero bytes, with the final byte containing a value small enough to brute-force across at most 255 candidates.
This catastrophic weakness allowed for immediate recovery of the private keys. The identified values were:
- 4
- 56
- 66
- 115
- 155
- 156
- 230
- 237
Despite their minuscule size, these integers still produce mathematically valid public key points on the curve. This means the certificates passed standard structural checks, masking the underlying cryptographic fragility. Google Chrome and Firefox quickly blocked these certificates, with Apple and Microsoft following suit.
The mistake had a paper trail—and a missed alarm
The reported cause traces to an April 2025 key ceremony where eMudhra modified a script to test key exports. This script inadvertently generated weak extra key pairs on the Hardware Security Module (HSM). Operators, misled by similar labels, then used these compromised keys for certificate requests, rather than the intended cryptographically strong ones.
Crucially, a warning surfaced in June 2025. Sectigo, the cross-signer, reported invalid signatures on eMudhra's Certificate Revocation Lists (CRLs). This mismatch occurred because eMudhra attempted to sign the CRLs with its original, strong keys, which did not correspond to the weak keys embedded in the issued certificates.
Instead of investigating the underlying discrepancy, eMudhra re-signed the revocation lists using the weak keys. This workaround effectively hid the symptom, allowing the fundamental security flaw to persist for 16 more months.
Operationally, this incident underscores two critical lessons. Key ceremonies demand independent identity and strength checks on all generated cryptographic material. Furthermore, any signature mismatch, particularly in a public key infrastructure context, must trigger an immediate incident response rather than a superficial workaround.
Browsers had guardrails. Build systems often don’t
Sectigo cross-signed the eMudhra intermediates, giving them broad reach across platform trust stores. Researcher Wayne demonstrated control by signing a proof message, "We have a problem here," with each of the eight compromised keys. This confirmed the keys' compromise and highlighted the widespread potential for misuse.
Browsers like Google Chrome and Mozilla Firefox swiftly revoked the certificates, often within hours. They enforce Certificate Transparency (CT) logs, publicly recording all trusted TLS certificates. Browsers typically reject certificates not present in these logs, a critical safeguard that prevented direct browser exploitation.
However, non-browser clients often lack these robust defenses. Tools such as curl, Python, Node, Go, and Git frequently rely on local CA bundles, skipping CT or revocation checks entirely. This leaves them vulnerable to machine-in-the-middle (MITM) attacks.
The practical stakes are substantial. An attacker wielding one of these forged keys could target:
- API calls
- Installation scripts
- CI runners
- Cloud credentials
The two compromised code-signing keys also raised concerns about forged software, potentially distributing malicious updates or applications. For further technical details, see the Mozilla Bugzilla: eMudhra Private Key Compromise of Intermediate Certificates.
Enjoying this? Get one like it in your inbox each morning.
one email a day · unsubscribe in two clicks · no third-party tracking
Patch the trust store, then test the whole pipeline
Browser vendors and platform operators moved quickly to distrust affected certificates. Apple, Google Chrome, Microsoft, and Mozilla blocked the compromised intermediates within days, while Sectigo ended its cross-signing arrangement with eMudhra. Go issued a targeted emergency release, version 1.27.3, directly blocking these eight intermediates within its standard library.
Device and software update coverage can still differ, especially for embedded systems. To mitigate risk, update your operating system and CA packages immediately. Bump language runtimes like Go to 1.27.3 and Python's certifi package to 2026.10.19. Rebuild container images and CI/CD runners to ensure all dependencies are current.
Test your clients against the published incident test endpoint, DV G3B eMudhra.we-have-a-problem.com. If your client rejects the certificate chain with an error, it is safe. This validation step is crucial for all systems that rely on certificate trust.
The incident underscores a critical PKI lesson: format checks cannot prove randomness or intent. Automate key-strength checks as part of key ceremonies. Validate that certificate public keys precisely match the intended HSM keys, not merely structurally valid ones. Monitor Certificate Transparency (CT) logs, and treat invalid revocation signatures—like Sectigo's June 2025 warning—as severe security emergencies.
Frequently Asked Questions
What was wrong with eMudhra’s private keys?
Eight intermediate CA certificates used tiny private-key values, including 4, instead of unpredictable 384-bit values. The corresponding keys could be recovered by testing only a few possibilities.
Were ordinary browser users at risk?
Modern browsers’ Certificate Transparency requirements helped block unlogged forged certificates, though protections and updates varied. Non-browser software often lacks equivalent checks.
Why were CI pipelines a concern?
Tools and services in build pipelines may trust local CA bundles without checking Certificate Transparency or certificate revocation, potentially accepting a forged server certificate.
What should developers do?
Update operating-system and language-runtime trust stores, rebuild affected containers, and test the certificate-validation behavior of non-browser clients and CI runners.

