The private keys of eight intermediate CA certificates from the Indian certificate authority eMudhra can be computed by anyone in under a second. With them, anyone can issue certificates for any domain, and clients that still trust the chain will accept them. Chrome, Firefox and Safari have blocked them. Edge on Windows 11 still accepted them when we tested at 00.20 on 21-10-2026. API integrations, IoT devices, robot vacuums, TVs, cameras and other equipment that talks to a cloud can stay exposed until 2039 if they trust one of the chains.

The full write-up with proof, test pages and patched versions: emudhra.we-have-a-problem.com

Browsers

Chrome and Firefox have blocked the intermediates since 17-10-2026, and Apple since 19-10-2026, with no action needed from the user as long as the browser has received the update (Mozilla). Mozilla and Chrome are also removing eMudhra's entire ECC root, emSign ECC Root CA - G3 (Bugzilla).

Chrome, Firefox and Safari only accept certificates that appear in the public Certificate Transparency logs (Chrome, Firefox, Apple). No certificates from the eight intermediates have been found in CT logs, so browsers that require CT were not attacked with them during the 17 months the keys were weak.

That only protects the past. The keys are now public, and anyone can submit a forged certificate to CT logs and get the receipts (SCTs) browsers require. CT does not check who owns the domain, so the attack becomes visible afterwards, but the browser accepts the certificate. From now on, only updates that block the intermediates protect a browser. The test pages carry exactly that kind of certificate, and Edge on Windows 11 still opened them in our test. An Edge installation that still accepts the chain can be attacked with a forged certificate for any website by anyone who can get onto the connection. Microsoft has not said when this will be fixed (Ars Technica).

Everything else

Equipment that talks to a cloud assumes the server is genuine when its certificate matches the list of root certificates in the device firmware. That covers API integrations between systems, IoT devices, robot vacuums, air conditioners, TVs, cameras, routers and printers. They rarely check CT or revocation (Scott Helme).

As long as the device does not get a new list of root certificates, anyone who gets between the device and the internet can impersonate the manufacturer's cloud with a certificate the device accepts. That can be on the same Wi-Fi, in a compromised router or at an internet provider. The chains work:

  • until 31-12-2028 if the device trusts Sectigo's old root AAA Certificate Services
  • until 09-07-2039, almost 13 years, if it trusts emSign ECC Root CA - G3
  • until 28-04-2040 if it trusts emSign Root TLS CA - G3 directly, as Windows does

One example: ESP-IDF, which ESP32 chips in IoT devices are built with, includes emSign ECC Root CA - G3 in its default list. A device that only trusts its manufacturer's own certificate is not affected.

Scott Helme made a forged certificate for api.stripe.com, and curl, Python and Node accepted it without an error (Scott Helme). These are the same libraries used in integrations and CI/CD pipelines.

A side effect for people who want to control their own gadgets

It may become easier to take control of your own robot vacuum, air conditioner or other device that insists on talking only to its manufacturer's cloud. If you sit between the device and the internet yourself, the device may accept a local server as the manufacturer's cloud, provided it trusts eMudhra's certificates. That alone does not give you control of the device, and we have not tried it on specific products. It is the same technique an attacker uses, and the certificates are for a domain you do not own. Projects such as Valetudo have freed robot vacuums from the cloud by other means for years.

Who eMudhra is

eMudhra is a listed Indian company based in Bangalore, founded in 2008, with revenue of 7,016 million rupees, about 66 million euro, in the financial year ending 31-03-2026. It is India's largest issuer of digital signatures, with about 38 % of the market (eMudhra's earnings presentation).

TLS certificates are 6 % of eMudhra's certificate revenue. About 30,000 TLS certificates sit under the root that Mozilla and Chrome are removing, and 97 % of them were issued through ACME (Bugzilla). Outside India, eMudhra sells under the name CertiNext, and since April 2026 it has supplied the certificates in InCommon, the shared certificate service for US universities.

Sectigo cross-signed the affected intermediates under AAA Certificate Services. That adds another path to trust, but the weak keys are eMudhra's. Sectigo's own keys are not affected.

What went wrong

A P-384 private key should be a random 384-bit number. These eight keys are numbers between 4 and 237. Scott Helme computed them from the public certificates in under a second by trying the numbers from 1 upwards, and Mozilla had AI agents find them on the first attempt (Bugzilla).

According to eMudhra, a bug in the script used at the key ceremony on 30-04-2025 created a second set of weak keys in the HSM, and they were used by mistake because their names resembled the real ones (Bugzilla). The fault was visible in May 2025, when the intermediates' CRLs had invalid signatures.

Test your equipment

Open the test page in your browser. It tries to connect to 12 test sites with certificates from the compromised intermediates, through both eMudhra's and Sectigo's root. "✅ Did not connect" for all 12 and "connected to 0 of 12" at the bottom is the correct result. "❌ Connected" means the browser trusts the broken certificates. The page cannot tell a certificate error from a network that blocks the address, so also test from a network without filtering.

For servers and integrations, run from the machine or container the integration runs in:

curl https://dv-g3b-emudhra.we-have-a-problem.com/
curl https://dv-g3b-aaa-emudhra.we-have-a-problem.com/

A certificate error is the correct result. If the page loads without an error, the client still trusts the compromised intermediates. A timeout or DNS error does not prove the client is protected.

How to fix it

1. Update everything that can be updated. Browsers, operating systems and Docker images, which need rebuilding with the new packages. Ubuntu, Debian, Alpine, Arch, Gentoo, Go, Python certifi, pip and curl's CA bundle are updated. Fedora, FreeBSD, Node.js and Bun are still pending. See the current table on the page.

2. Windows: block the certificates yourself. Until Microsoft ships an update, you can put all 16 certificates (eight keys, each in two versions, including the two for code signing) in Windows' store for untrusted certificates. Run PowerShell as administrator:

$ErrorActionPreference = 'Stop'
[Net.ServicePointManager]::SecurityProtocol = 'Tls12'
$certs = Invoke-RestMethod 'https://emudhra.we-have-a-problem.com/impacted-intermediates.json'
foreach ($c in $certs) {
    $file = Join-Path $env:TEMP ($c.sha256 + '.crt')
    Set-Content -Path $file -Value $c.pem -Encoding Ascii
    certutil -addstore Disallowed $file
    if ($LASTEXITCODE -ne 0) { throw "Import failed for $($c.sha256)" }
    Remove-Item $file
}

For many machines: save the 16 certificates as files and import them in Group Policy under Computer Configuration → Policies → Windows Settings → Security Settings → Public Key Policies → Untrusted Certificates. Then test in Edge on the test page.

3. Linux and macOS. Install your distribution's updated certificate package, usually ca-certificates. Temporary workarounds for distributions that have not shipped one yet, and for the built-in macOS /usr/bin/curl, are on the page.

4. Integrations and pipelines. Find out which list of root certificates each integration uses: the operating system's, Python certifi, a Java keystore or a file shipped with the program. Update it, restart the process and test from the same environment. Go programs need rebuilding with an updated Go version. Start with CI/CD and install scripts (curl | sh), because they hold keys and tokens.

5. Equipment. Ask the vendor whether the firmware trusts any of the three roots above, and when an update will ship. Equipment that gets none can be isolated and limited to the connections it needs. That reduces the risk but does not fix the fault. If the risk is unacceptable, cut the device's connection to the cloud.

Do you need to replace your own certificates?

Only if they were issued by eMudhra, including under the names CertiNext or InCommon, with a chain to emSign ECC Root CA - G3. That root is being removed from Firefox and Chrome, and eMudhra is moving customers to chains under the RSA root emSign Root CA - G1, which is not being removed. Check the issuer, and ask eMudhra whether your chain needs to change:

openssl s_client -connect www.example.com:443 </dev/null 2>/dev/null | openssl x509 -noout -issuer

Sources