Eight eMudhra CA Keys Were Compromised, and Only One Outlet Says How

Mozilla blocked eight eMudhra intermediate certificate authority certificates in Firefox less than three hours after a report on October 17 that their private keys were compromised, the Firefox Security Team said on October 20.

An attacker holding one of those keys could issue HTTPS certificates for sites they do not control, according to Mozilla's post. To use one against a user, the attacker would also need to sit on the user's connection. The post does not list the eight certificates, does not name the root and does not say how the keys were exposed.

The October 17 timeline, hour by hour

Mozilla received the report at 20:06 UTC and the updated OneCRL list reached Firefox installs with standard settings at 22:59 UTC. The Hacker News, which gives a fuller timeline, says Chrome's root program received the same report at 18:05 UTC and had a CRLSet update out by 19:45 UTC.

Apple blocked the certificates on October 19 and Microsoft on October 20, The Hacker News reports. A site run by the researcher's supporters, emudhra.we-have-a-problem.com, says the reporter, credited only as "Wayne", signed the message "We have a problem here - Wayne" with each of the eight keys as proof.

The Hacker News lists the eight as six TLS intermediates (domain, organization and extended validation, each in a G3B series for eMudhra BV of the Netherlands and a G3C series for eMudhra Inc of the US) and two code-signing intermediates. It credits Dennis Jackson, a Mozilla cryptography engineer, with publishing the certificate list and signatures.

Where the accounts disagree on cause

Fenko Security's Ali Mosajjal wrote on October 20 that eMudhra revoked all eight on October 18 with the reason code cACompromise, and that no incident report existed. Reason code 2, he wrote, "says the key is believed exposed. It doesn't say how, and nobody has."

heise went further. Its report, by Dr. Christopher Kunz, says the EC-384 keys were each a number between 0 and 255, one of them "4", and corrected an earlier version that had called the keys stolen. That correction was posted October 20 at 19:06. heise also says an attacker would need control of DNS or IP routing to exploit this against users.

No other source read here repeats the 0-to-255 detail, and Mozilla's wording remains "compromised". Treat it as reported by one outlet.

What was in certificate transparency logs

Mosajjal reports that none of the eight CAs has logged a certificate to certificate transparency logs in roughly 18 months. That leaves two readings, he wrote: the CAs sat idle, or something was issued without being logged. He found public evidence for neither.

Which software needs updating

Firefox users on standard settings were covered by the OneCRL push. Everything that does not read revocation data needs a new build. The list below is from the we-have-a-problem site and The Hacker News.

Software	Fixed version	Date or note
Firefox / Android	158.0.1	October 20
Firefox ESR	115.43.1, 153.5.1	October 20
NSS	3.131.1	Removes emSign ECC Root CA - G3
Go	1.27.3, 1.26.10	CVE-2026-111943; no fix for 1.25 and older
Python certifi	2026.10.19	Drops emSign ECC Root CA - G3
pip	26.2.2	Per we-have-a-problem

Node.js, Bun, Composer, FreeBSD and Debian (bug 1151413) were still pending when the we-have-a-problem page was published. On macOS, it says, /usr/bin/curl does not check revocation and reads /etc/ssl/cert.pem, which has not been updated.

For a second look at how a single constant can undermine trust in a cryptographic scheme, see our report on NIST P-256's seed. For another attack on integrity, this one against model weights, see the GPU-memory tampering demo.

Mozilla's post ends with one commitment: "We will share more information as soon as circumstances allow." Chrome, per The Hacker News, will remove emSign ECC Root CA - G3 in root store version 43.