eMudhra CA Compromise: Are Your Embedded Devices at Risk?

On October 17th 2026, eight intermediate CA certificates were reported as compromised to the Root Program Teams. The private keys linked to the public keys of these intermediate certificates were weak, meaning anyone could forge valid TLS certificates.

These intermediate CA certificates chain to roots trusted by the Mozilla root program, among others, which is itself packaged by embedded devices operating systems, distributions, package managers, or packages (e.g. curl). These roots are part of the trust store which is used the code running on the device to verify whether it should trust certificates signed by up the chain. In a nutshell, the trust store is the list of trusted certificates that applications running on your embedded device use to verify certificates.

The root programs and their downstream consumers have removed the compromised intermediate CA from their trust stores to protect end users. For this to take effect, trust stores must be updated where it is used. This happens fast for applications like browsers (Firefox and Chrome acted on October 17, 2026) or operating systems (Microsoft on October 20, 2026 and Apple on October 22, 2026). For embedded devices, trust store update are not always automatic and may require the vendor to package a new firmware update and either wait for clients to check-in to receive their update or push it down to devices, if auto-update is even a thing.

Impact

The compromised keys can be abused by attackers to forge valid TLS certificates and impersonate any remote service contacted by embedded devices. Anything from firmware update, telemetry, cloud message brokers would be open for interception and manipulation by an attacker-in-the-middle.

This completely breaks confidentiality and integrity of all TLS communication with upstream services.

Am I Affected ?

When running a firmware analysis, our pipeline collects all cryptographic material including public keys, private keys, and certificates, regardless of how they’re stored or encoded. These are saved in the analysis database and exposed over the API so that you can query it directly or access it using the frontend in the “Artifacts” section.

So the first step you can take is to search for the compromised keys in your firmware corpora. To do so, go to “Search In” → “Artifacts” and filter on the subject.

You can click on artifacts to have a detailed view:

A list of affected certificates was published by Dennis Jackson on eMudhra Intermediate CA Compromise . You can use it to search in your own Artifacts.

This will give you a good overview of how many devices and product lines are affected so you can start prioritizing patches. However, manual hunting may not scale if you have hundreds or thousands of those firmware. That's what monitoring is for.

Will I be Notified ?

Once keys and certificates are collected, we run security checks looking for a variety of cryptographic and transport security related issues (expired certificates, insufficient key length, invalid signatures, obsolete signing algorithm, CA mismatch, obsolete certificate version, certificate with invalid RSA key exponent, …).

As part of those checks, we verify certificate chains using up-to-date ca-certificates (a list of trusted Certificate Authorities published by Mozilla) coming from certifi.

If monitoring is enabled on your firmware analysis, you’ll see that a new issue (“Certificate CA Verification Failed”) is now reported.

When opening the issue details, we can see that the eMudhra certificate (emSign ECC Root CA - G3) should not longer be trusted.

This certificate is part of the device trust store (/etc/ssl/certs/ca-certificates.crt), which means you should upgrade to the latest version of ca-certificates.

Of course, you can always check the exact version of  ca-certificates you are using by consulting the SBOM. Here we see it’s running version 20241223 from December 23, 2024.20241223.

Key Takeaways

• Private key compromise are always bad, and even worse when they belong to keys trusted by the entire Web PKI ecosystem.
• Modern browsers and operating systems were patched fast since they have access to auto-update mechanism and can rely on Certificate Revocation Lists (CRL) as a last resort. Embedded devices take longer to patch and very rarely verify CRLs.
• To assess your exposure, either enable monitoring on your firmware analysis to be notified or perform a hunt by searching for indicators of these compromised keys in your Artifacts, either at firmware level or through your entire firmware corpora.
• Our AI assistant is there to help, don’t hesitate to ask it whether you are affected by this incident. It will bring up affected firmware and link to the artifacts.

‍