One of the compromised eMudhra private keys had a value of 4, a rarity so stark that a published key proved the certificate could be forged almost instantly, researchers say.
eMudhra: a script error, tiny private keys, and eight revoked intermediates
Researchers discovered the flaw on October 17 when a security researcher known as Wayne was scanning publicly available certificate data. According to Mozilla's incident report, eight eMudhra intermediate certificates used P-384 private keys generated in April 2025 that had values smaller than 256 — small enough that an attacker could recover a key by testing at most 256 possibilities.
Security researcher Flüpke published one of the compromised private keys on GitHub to demonstrate the weakness, showing that the private key for eMudhra's "EM OV TLS CA - G3C" certificate had a literal value of 4. BleepingComputer independently verified that the published key matches one of the revoked certificates.
In response to Mozilla, eMudhra said the problem was caused by an error in a script used to generate certificates in April 2025. The company said the script produced a second set of weaker keys that were mistakenly selected for certificate signing because they had labels similar to the properly generated keys. eMudhra reported that most of the affected intermediate certificates were never used in production and that the company found no evidence they were used to issue certificates to end users. eMudhra nonetheless revoked the eight compromised certificates and stopped issuing new certificates under its G3 root.
Browser and operating-system vendors moved quickly to block trust
Major browser makers and operating systems pushed protections after the disclosure. Mozilla said it blocked the compromised certificates through Firefox's OneCRL system on October 17, an action that protected users without requiring a browser update or restart. Google Chrome blocked the six compromised intermediates that were authorized to issue TLS certificates that same day, while Apple added protections on October 19.
Mozilla released Firefox 158.0.1 and updates for its ESR releases on October 20 to protect users whose browser configurations prevented them from receiving the earlier OneCRL revocation updates. The advisory notes, however, that software which uses its own certificate stores or does not check certificate revocations may continue trusting the compromised intermediates until it is updated.
This site is the portfolio.
OSINTSights runs on Cloudflare Workers, D1, R2, and Vectorize, with an AI pipeline on Hetzner ARM. Nubivance designed, built, and operates it. We do the same for clients.
See what we buildDeveloper and platform effects: Go updates, macOS curl, and incident tracking
The Go development team released versions 1.27.3 and 1.26.10 to address the issue; the fix is tracked as CVE-2026-111943. Mozilla cryptography engineer Dennis Jackson published an incident-tracking website listing affected software and available security updates and warned that macOS's built-in /usr/bin/curl utility may continue to trust the compromised certificates because its certificate bundle does not check revocation information.
Jackson's tracking page also provides test endpoints and mitigation instructions that administrators can use to determine whether their systems are still affected. The advisory encourages administrators to run those checks and to apply vendor updates where available.
What this means for technologists, administrators, and end users
- Technologists and security teams: validate that your TLS stacks and certificate-validation libraries consult revocation information; apply the Go updates (1.27.3 / 1.26.10) and browser patches; and use Mozilla's test endpoints and Dennis Jackson’s tracking resource to enumerate and remediate impacted systems.
- Administrators and enterprises: inspect any systems that use custom certificate stores or embedded certificate bundles (including appliances and build environments). Because some intermediates were cross-signed by Sectigo, check for cross-signed chains in inventories and revoke or reissue internal certificates if they derive trust from the affected intermediates.
- End users and the general public: install the browser and OS updates pushed by vendors. While eMudhra said it found no evidence the weak keys were used to issue end-user certificates, attackers could have recovered and abused the weak keys since their creation in April 2025, so applying updates and following vendor guidance remains the prudent course.
The case is a stark, narrow reminder that a tooling mistake in certificate generation can create an outsized risk: tiny, low-entropy private key values in a trusted intermediate allow forgery and interception without sophisticated cryptanalysis. Vendors and administrators have acted quickly to block trust and publish patches, but systems that do not consult revocation information or that maintain separate certificate stores remain potential blind spots. Administrators should use the published test endpoints and mitigation instructions, and users should install available updates to ensure the compromised certificates are no longer trusted.
Source: BleepingComputer — Mozilla, Google, Apple block compromised eMudhra CA certificates
