Private Key Was the Number 4: A Key Incident That Shook the Entire Industry
Start with a number: 4. Last week, security researcher Scott Helme recovered eight CA private keys in under a second on his laptop—one was the integer 4, and the other seven were also integers below 256. These eight private keys were supposed to protect the authority to issue "trusted" certificates for any website on the internet. The incident is tracked as CVE-2026-111943, and Go's emergency release last week was issued because of it.
Background
When you visit a website, the server presents a certificate proving "I am this domain." Certificates don't appear out of nowhere: website certificates are signed by intermediate CAs, which hang below root certificates pre-installed in your OS and browser. Anyone holding an intermediate CA private key can issue certificates for any domain—banks, email, government sites—and your software will accept them all.
What Went Wrong
The eight private keys belonged to eMudhra, an Indian CA operating under the emSign brand. On April 30, 2025, they held a key ceremony, batch-generating 24 intermediate certificates. The ceremony ran on certified hardware security modules (HSMs)—but HSM certification attests to the device, not the scripts running inside it. eMudhra later explained: a script error generated a second set of weak keys with labels similar to the correct ones, and the team used the weak set for certificate signing requests. The weak set was what went out to the major root stores.
How weak? The intermediate certificates used elliptic curve P-384, where the private key should be a random number near 384 bits. The actual values of these eight were between 4 and 237. The elliptic curve relationship is: public key = private key × a fixed curve point. If the private key is 4, multiply the fixed point by 4 and compare against the public key printed in the certificate—it matches. Try each value in turn: at most 255 attempts. The researcher noted that a modern AI agent could complete this with a single prompt.
The Missed Warning
Dramatically, an alarm did sound once. In June 2025, six revocation lists signed by these intermediate CAs failed signature verification—because they had been signed with the original keys first. This anomaly was not treated as an alarm at the time.
Disclosure and Response
Formal disclosure came on the evening of October 17, 2026. An independent researcher signed a fixed message with each private key and submitted the evidence to the major root programs. Chrome received the report at 18:05 and pushed enforcement at 19:45—one hundred minutes. Mozilla finished by 23:00 the same night. Apple followed on the 19th, Microsoft on the 20th. A review of Certificate Transparency logs found no fraudulently issued certificates: in the year and a half from April 2025 to October 2026, either nobody discovered the keys, or whoever did didn't act.
The Go Problem
Go's TLS verification uses its own standard library crypto/x509, reading trust from the system's root certificate directory. The problem: Linux root certificate packages can automatically distribute "trust"—a distribution update delivers new roots to billions of machines—but there is no channel for "this intermediate certificate was revoked." Revocation status requires applications to actively check CRLs or OCSP, and Go's verification doesn't check by default. Worse, some of the eight intermediate certificates carried cross-signatures from Sectigo's old AAA root—removing eMudhra's own root still left this path open. An attacker with the leaked key signs a certificate for any domain, presents the revoked intermediate during the handshake, the chain verifies up to a trusted root, and the verification function returns it to the caller as-is. The application sees: verified, trusted.
The Fix
The fix is direct: hardcode the SHA-256 hashes of the eight public keys into the standard library. During candidate chain filtering, any chain containing one of these eight hashes is removed entirely; the Windows and macOS system-verification paths apply the same filter. Upgrade to Go 1.27.3 or 1.26.10 to get it. Debian went further, removing the two roots from the system trust package outright.
The Deeper Lesson
The most important takeaway: trust is distributed by push, revocation is distributed by pull. Root certificates arrive on your machine automatically with system updates; revocation information must be fetched by applications, and most don't. This week the whole industry worked to convert "pull" into "push": browsers fetching their own revocation lists, Go compiling hashes into the binary, distributions removing roots. But push has limits—old containers nobody updates, language runtimes shipping their own CA file. In those corners, trust is still frozen at April 2025. Certificate verification returning "pass" only means: signature valid, not expired, chain reaches a root. It does not mean the key wasn't leaked. What the verifier doesn't say, callers have always assumed it did.
References: Go issue 82345 / golang-announce 2026-10-20; public advisories from eMudhra, Cloudflare, Mozilla, and the Chrome Root Program (2026-10-19 to 21). Recommendation: upgrade to Go 1.27.3 / 1.26.10.