eMudhra certificate compromise: 8 CA keys guessable in 256 tries

The padlock in your browser rests on a chain of trust. This week one link in that chain turned out to be a number you could guess. In the eMudhra certificate compromise, eight intermediate certificate authority keys were so weak that anyone could recover them by testing fewer than 256 values. With one of those keys, an attacker could forge a TLS certificate for any domain. Browsers blocked the certificates within days. The harder problem is everything that isn't a browser: your servers, containers, payment SDKs, and background jobs.

What actually happened

Per Help Net Security, a researcher found the flaw on October 17 while checking the Common CA Database and reported it to Apple, Google, Microsoft, Mozilla, and eMudhra. Mozilla's Dennis Jackson made it public on October 20.

The details:

• Eight intermediates, from a batch of 24 generated on April 30, 2025. Six issue website TLS certificates; two are for code signing. Sectigo cross-signed all eight in May 2025.
• The keys were small numbers. A real private key is a random number over 100 digits long. These were below 256. Scott Helme recovered them from the public certificates in under a second.
• Browsers moved fast. eMudhra revoked the certificates on October 18. Chrome and Firefox blocked them on the day of the report, Apple followed on October 19, and Microsoft on October 20. Mozilla also removed trust in the eMudhra root.
• eMudhra's explanation: a faulty script during the 2025 key ceremony created a second set of weak keys with similar labels, and staff picked the wrong ones. eMudhra says none were used to issue customer certificates. Whether anyone else found the keys in the 17 months since is unknown.

Cloudflare's incident post says it learned of the issue October 19, pushed fixed WARP, 1.1.1.1, and cloudflared (2026.10.2) builds by October 20, and found no active exploitation on its services. Its warning: browsers get fixes quickly, but apps with bundled trust stores and services that inherit trust from an unpatched library stay exposed until someone updates them.

Why the eMudhra certificate compromise matters for your business

Your customers' browsers are fine. Your back office might not be. A Node service calling a payment API, a Python script pulling orders, an old Docker image running your webhook handler: each one checks certificates against whatever trust store it shipped with. If that store still trusts these intermediates, a forged certificate could get through.

Updating the SDK isn't always the fix. Cloudflare notes that an SDK may hand verification to an HTTP library, the language runtime, or the OS. Bump the package, rebuild the image, and restart the process. A container still running last month's image is still running last month's trust store.

Never "fix" a TLS error by turning off verification. If an update breaks a connection, that's the update working. Disabling verification removes the protection you just restored.

A curl test from your laptop proves nothing about your server. Test the actual TLS path of each service, from where it runs.

Sources: Cloudflare, Help Net Security.