eMudhra CA keys of 1 to 255 enabled forged certificates; Oracle shipped a second Java fix

What happened

On 17 October 2026, an unknown party demonstrated possession of the private keys belonging to eight intermediate certificate authorities operated by eMudhra, signing a short message with them: “We have a problem here - Wayne.” According to a detailed write-up on dev.to, six of the eight CAs are trusted for TLS by Chrome, Firefox, Safari and Windows, while the remaining two are trusted by Windows for code signing. The same keys also appear in eight cross-signatures from Sectigo.

Nothing was stolen in the conventional sense. Citing Mozilla's analysis in the incident report, the article explains that each key was an integer between 1 and 255 — a P-384 private key whose 48 bytes are all zero except the last one. Anyone holding the public certificate could test all 255 candidates almost instantly; one measurement cited in the article puts the full table at 28.7 milliseconds. The key belonging to EM OV TLS CA - G3C is verifiably the number 4.

Whoever controls such a key can mint a certificate for any hostname. The only additional requirement is a position on the network path between client and server, and clients that trust the roots while skipping revocation checks and Certificate Transparency have no way to detect the forgery.

How weak keys passed every check

Per eMudhra's preliminary explanation in the incident report, the keys were generated on Utimaco hardware security modules during a ceremony on 30 April 2025. An approved deviation added a test of key wrap and unwrap. A flaw in that test code produced a second, weaker key pair inside the HSM, and because its label resembled the intended one, the weak pair was submitted in the certificate signing requests. The root CA signed them, and Sectigo cross-signed the result.

Nothing downstream objected, because P-384 itself is sound and a key of 4 is mathematically valid: it parses, signs and verifies like any other. Format validation and sign-and-verify tests all passed, which the article identifies as the reason the problem went unnoticed for almost eighteen months.

The chain served by the incident's test host shows the shape of the problem: a leaf certificate, then EM DV TLS CA - G3B (one of the weak intermediates), then emSign Root TLS CA - G3, anchored at emSign ECC Root CA - G3 in the client's trust store. The intermediates carry CA:TRUE with pathlen:0 and no name constraints, so nothing in the certificates themselves restricted which hostnames they could vouch for.

Who is actually exposed

Browsers moved quickly: per the dev.to article, Chrome and Firefox were protected within hours, and Windows and Apple devices within days. The gap is TLS outside the browser. Trust is not a property of the TLS protocol; each runtime picks its own root-certificate file. Patching the operating system updates curl's view of the world but does nothing for Node, for a Go binary compiled a month earlier, or for the certifi bundle inside a virtualenv. Most non-browser clients check neither CRLs, OCSP nor Certificate Transparency logs by default, leaving them open to certificates issued from the compromised CAs.

The second Java fix

The patch guidance is still shifting. On 24 October 2026, Oracle shipped a second Java fix, CVE-2026-114820, meaning advice written earlier — including any material describing Java builds as remediated — is out of date. The article, current as of 25 October, directs readers to the incident site's patch list for the newest state.

What to do

The remedy the article settles on is twofold: update each runtime together with its trust store, then rebuild everything that embeds them — statically linked Go binaries, container images, virtualenvs and bundled JDKs. For Java specifically, treat any fix status stated before 24 October as unreliable and re-verify against the current patch list.

Why it matters

The incident demonstrates that TLS trust is only as strong as the weakest key anywhere in the chain above your connection, and that the trust store is a per-runtime choice which operating-system patches do not propagate. It also exposes the limits of conventional CA quality assurance: keys this weak passed every format and signature test for a year and a half, and were caught only when someone publicly demonstrated them. Finally, the second Oracle CVE is a reminder that during a live security incident, patch guidance has a shelf life measured in days, and advice needs re-checking rather than archiving.