The private key was 4: eMudhra intermediates and non-browser TLS trust

A P-384 elliptic curve private key is supposed to be a randomly chosen integer in the range [1, n-1] where n is the curve order (~2^383). eMudhra's EM OV TLS CA-G3C intermediate certificate was issued with a private key scalar of 4 — a value trivially guessable by enumeration and trivially invertible from the public key using a lookup table. This is not a weak random number generator story. The key is four.

Talos Intelligence and BleepingComputer published technical details. Mozilla Bugzilla 2083449 tracks the revocation and distrust actions. Ryan Hurst's write-up walks through how the keys were recovered.

What the key weakness means

For an EC key, the private scalar d and the public point Q are related by Q = d·G where G is the curve base point. With d = 4, Q = 4·G — computable from the public key in microseconds. An attacker who knows the intermediate's public key (visible in any TLS handshake from a server using a leaf signed by this intermediate) can recover d trivially and forge certificates for any domain that chains to EM OV TLS CA-G3C.

This is not a vulnerability that requires exploitation; it is a broken issuance. The intermediate CA's signing key is effectively public.

Browser blocking vs. non-browser trust

Browsers that have updated their built-in CA stores will reject TLS connections presenting certificates signed by the compromised EM OV TLS CA-G3C intermediate. Chrome, Firefox, Edge, and Safari CA program operators have revoked or distrusted the intermediate.

Non-browser TLS clients often use their own trust stores or the OS trust store, without the additional CA quality checks browsers implement. CVE-2026-111943 tracks the Go ecosystem impact — Go applications that trust system root CAs (the default) or that bundle the affected intermediate may accept forged certificates signed by the attacker-recovered key.

Client class exposure matrix

TLS verification paths

Operator implications mid-engagement

On a network you are testing:

• If you capture a TLS handshake that chains to EM OV TLS CA-G3C, the server is using a certificate signed by the compromised intermediate. This is a certificate-chain finding regardless of whether active exploitation is in scope.
• Internal services that perform server-to-server TLS validation (microservices, container sidecars, VPN tunnels) may trust the compromised intermediate through their OS or base-image trust store. This is worth enumerating.
• Go microservices are the highest-probability exposure. Run go version on a foothold host, then check whether the application validates peer TLS certificates (InsecureSkipVerify: false is the secure default but trust store currency is a separate question).
• Frozen Docker base images (months-old debian:slim, ubuntu:22.04, etc.) will carry stale trust stores and may be vulnerable to a MITM with a forged certificate if they initiate outbound TLS.

Evidence to capture:

• Certificate chain dumps: openssl s_client -connect host:443 -showcerts
• Go runtime version and TLS dialer configuration from source or binary strings
• Container base image and build date (from docker inspect or cat /etc/os-release on the container)

Remediation advice for the report:

• Browser users: update browsers and OS.
• Go applications: update Go runtime to a release that picks up the trust store change; ensure system CA package is current.
• Containers: rebuild base images with current OS security packages.
• Network appliances and VPN clients: follow vendor advisory for trust store update.