eMudhra CA Compromise: What Cloud Security Teams Need to Know

Executive summary

On October 17, a researcher reported control of eight eMudhra intermediate certificate authority private keys. Mozilla independently recovered the keys and confirmed that their generation was flawed.

The technical finding is severe: the affected P-384 private keys were integers below 256, making them trivially recoverable from public information. Describing this simply as a key leak understates the problem. These keys were inherently weak, so defenders should assume that anyone could have derived them. 

An attacker holding an affected TLS intermediate key could create fraudulent certificates for services they do not control. If the attacker can intercept or redirect a connection, and the client still accepts the affected certificate chain, they could impersonate the destination and potentially read or modify traffic.  In cloud environments the impact can go further: services that accept client certificates as proof of identity could accept a forged one.

Browsers are already protected. Most server-side software is not: it does not check revocation and keeps trusting the affected chains until its trust bundle or runtime is updated. Many of those fixes have no formal advisory, so vulnerability scanners may not flag them.

What was compromised?

The incident affects eight intermediate CA keys: six associated with TLS certificate issuance and two with code signing. The affected intermediates also have Sectigo cross-signed certificates, creating additional certificate paths using the same keys. In total, 16 certificates use the eight compromised keys.

An intermediate CA sits between a trusted root and the certificates issued to individual services:

Trusted root CA → Intermediate CA → Service certificate

Compromising an intermediate’s private key undermines the trust placed in certificates it can sign. The signature on a fraudulent certificate can be mathematically valid even though the service identity is false.

This does not mean an attacker can automatically decrypt every HTTPS connection. Exploitation still depends on reaching the victim’s traffic and encountering a client that accepts the compromised chain.

How do the keys reach trusted roots?

Because of the cross-signs, the affected intermediates reach widely trusted roots through two paths:

• Sectigo “AAA Certificate Services”: Mozilla and Chrome have removed it, but it is still trusted by Apple and Microsoft and is present in many older Linux and language CA bundles.
• “emSign ECC Root CA – G3”: included in all four major root programs (Mozilla, Chrome, Apple, Microsoft). The disclosure data lists it as a cross-signer of eMudhra’s issuing roots.

This explains why an image with a reasonably recent CA bundle can still be exposed, and it tells teams exactly which roots to look for in their trust stores.

Is code signing affected?

Two of the eight keys belong to code-signing CAs (“EM OV CS CA – G3B” and “EM OV CS CA – G3C”), which chain to roots in Microsoft’s store. Someone holding these keys could sign software that Windows treats as coming from a verified publisher. Windows servers, virtual machines and endpoints are therefore in scope, not only TLS clients.

Is it being exploited? 

We found no verified list of attacker IPs or domains in the published material.The disclosure website and public test endpoints should not be labeled attacker infrastructure merely because they demonstrate the issue.

As of October 20, Certificate Transparency (CT) logs, the public record of every publicly trusted TLS certificate, contain no end-entity certificates issued by any of the eight compromised intermediates; only the intermediate certificates themselves are logged. Blocking these chains therefore breaks no legitimate public site. An attacker may not log a forged certificate, and most non-browser clients do not require CT, so this does not rule out unlogged use.

Can a forged certificate grant cloud access?

Several cloud services accept a client certificate as proof of identity, and trust a CA bundle that the customer configures. If that bundle includes an affected root or intermediate, a forged client certificate could be accepted as a legitimate identity:

• AWS IAM Roles Anywhere trust anchors and GCP workload identity federation with X.509: a forged certificate could be exchanged for cloud credentials.
• mTLS on load balancers and API gateways: AWS ALB trust stores, API Gateway custom domains, Azure Application Gateway, GCP load balancers with TrustConfig.
• Device and network access: AWS IoT and Azure IoT Hub CA registrations, AWS Client VPN, Azure point-to-site VPN root certificates.

These configurations are worth reviewing even where no workload trusts the chain for outbound connections, because a forged client certificate gives an attacker direct access.

Does revocation protect my servers?

eMudhra has revoked the affected intermediates, and browsers enforce that through their own mechanisms: Mozilla OneCRL and CRLite, Chrome CRLSets, and Apple’s equivalent. Mozilla completed its emergency OneCRL rollout for standard Firefox configurations on October 17. Its October 20 releases extend protection to configurations that may have missed that update, while NSS 3.131.1 removes the signing root from its trusted list. 

Most non-browser TLS clients do not check revocation by default. That includes OpenSSL-based tools such as curl, Python, Go, Java and Node.js. For these clients, a revoked intermediate stays trusted until the trust bundle or the runtime itself is updated. The revocation is real, but it does not protect most server-side workloads.

Are my containers affected? 

Cloud applications have a different update path from browsers and operating systems.

Go addressed the incident by changing crypto/x509 to reject chains containing the affected public keys. The change is tracked as CVE-2026-111943. Updating the Go installation on a build host does not change an already deployed executable; applications need to be rebuilt with a fixed toolchain and redeployed. 

Python applications may use certificate bundles distributed through their dependencies. The Python security announcement explicitly recommends upgrading affected packages and rebuilding container images to refresh system certificates.  pip is a special case: it always loads its own bundled copy of certifi in addition to the system store, so versions below 26.2.2 keep trusting the affected chains even after the operating system is fixed. Every virtual environment has its own pip and certifi.

Serverless functions follow the same logic. Deployment packages and layers often bundle certifi or another CA bundle, and they keep using it until the function is rebuilt and redeployed.

The operational implication is straightforward: a patched host does not establish that every application inside its containers uses updated trust decisions.

Where should I look? 

A single workload can draw trusted roots from several places at once. Checking only the operating system bundle misses most of them:

• Operating system bundles: /etc/ssl/certs/ca-certificates.crt, /etc/pki/ca-trust/, /etc/ssl/cert.pem, plus any local distrust lists.
• Python: certifi’s cacert.pem in every virtual environment, and pip’s bundled copy.
• Java: the JDK’s cacerts keystore.
• Root lists compiled into binaries: Node.js, Bun, Electron, Rust webpki-roots, and Go programs that embed x509roots/fallback. These cannot be fixed by updating a file; the binary must be updated or rebuilt.
• Language and framework bundles: PHP composer/ca-bundle, Elixir castore, curl’s cacert.pem.
• Configuration that redirects trust: environment variables such as SSL_CERT_FILE, REQUESTS_CA_BUNDLE, NODE_EXTRA_CA_CERTS and PIP_CERT, and Java’s javax.net.ssl.trustStore property.
• Windows certificate stores on servers and virtual machines, including the Disallowed store used to block certificates.

For each workload, the question is which of these stores the running process actually uses.

Will my scanner catch it? 

Most vulnerability scanners compare package versions against advisory databases. Coverage for this incident is partial and arrived late:

• Only a few fixes have formal advisories: certifi, uv, and the Rust webpki crates. Some appeared only on October 20, and some are published only in databases that common scanners do not read.
• Many fixes have no advisory at all, including Ubuntu and Alpine ca-certificates, pip, Go and Electron.
• Some platforms have no fix yet: Debian stable, Fedora and RHEL, Node.js and Bun.
• pip’s bundled copy of certifi does not appear as a separate package in an SBOM, so it cannot be matched on its own.
• Trust stores edited by hand, and root lists compiled into binaries, have no package version to match.

A clean scan is therefore not evidence of a clean environment. Teams should check package versions against the fixed versions in the remediation table below, and check trust bundles directly for the affected roots and intermediates.

How do I find exposed workloads?

Security teams should separate two questions:

Start by mapping application dependencies and deployed binaries to running workloads. Include system certificate bundles, application-specific bundles, and embedded runtimes. Prioritize applications handling credentials, sensitive API traffic, package downloads, or software updates.

CI runners and build pipelines deserve to go first. A forged certificate presented to a package download or a container registry pull becomes a software supply-chain compromise, not a single intercepted session.

An outdated package is a useful investigation lead. Determining exposure requires understanding which trust configuration the application actually uses.

How do I fix and verify? 

• Go: Upgrade to Go 1.27.3 or 1.26.10, or a later supported release, then rebuild and redeploy affected applications. Programs that embed golang.org/x/crypto/x509roots/fallback should also update that module.
• Python: The published announcement recommends at least certifi 2026.10.19, pip 26.2.2, uv 0.13.4, and sigstore 4.5.1. Update affected environments and rebuild images. Upgrade pip and certifi inside every virtual environment, not only the system Python.
• Operating system images: update ca-certificates and rebuild images. Where the distribution has not shipped a fix yet (Debian stable, Fedora and RHEL at the time of  writing), remove trust in the affected roots manually or block the affected intermediates.
• Cloud trust configuration: remove the affected roots and intermediates from mTLS trust stores, Roles Anywhere trust anchors, workload identity providers, IoT CA registrations and VPN root certificates.
• Other workloads: Follow runtime and distribution advisories, accounting for custom trust stores and application-specific certificate handling.
• After deployment: Verify that the application’s effective TLS verifier rejects affected chains. To check from inside a workload, run curl https://dv-g3b-emudhra.we-have-a-problem.com; it should fail certificate validation. Also test https://dv-g3b-aaa-emudhra.we-have-a-problem.com, which serves the chain through the Sectigo cross-sign, so both trust paths are covered. Run the test with the application’s own runtime, not curl from the host: curl uses its own trust bundle, which may differ from the one the application loads.

Fixed versions, verified against distribution and package registries on October 21, 2026. Entries marked “No fix yet” change daily; recheck on the day of publication.

The eMudhra incident makes certificate trust an immediate cloud security concern. Effective response requires connecting the affected trust material to the applications that use it, the workloads running those applications, the cloud services configured to trust it, and the network activity that determines their exposure.

Appendix

Indicators of Compromise 

The published indicators identify compromised CA certificates and keys. They are useful for hunting and exposure assessment, but a match alone does not establish that a workload was attacked.

The disclosure provides these reference datasets:

• impacted-intermediates.json: affected intermediate certificates and their Sectigo cross-signs.
• roots.json: associated root certificates, useful for assessing trust paths.
• Mozilla incident inventory: certificate fingerprints, serial numbers, and investigation details.

Certificate SHA-256 Fingerprints

The following fingerprints identify all 16 affected certificates: the eight originals listed in Mozilla’s incident record and their eight Sectigo cross-signs.The following fingerprints identify the eight original intermediate certificates listed in Mozilla’s incident record. This table does not include the additional cross-signed certificates. Use the linked inventory and dataset for that coverage.

How do I match on public keys? 

For runtime rules, match SHA-256 hashes of the DER-encoded SubjectPublicKeyInfo (SPKI) in certificate chains. Public-key matching can identify the same compromised key across different certificates, including cross-signed versions. Go uses this approach in its mitigation. 

Each original intermediate and its cross-sign share one key, so these eight values cover all 16 certificates. The Subject Key Identifier is also listed: any certificate whose Authority Key Identifier equals one of these values was issued by a compromised CA.

Conceptually:

IF a peer certificate chain contains a compromised SPKI hash

THEN alert with workload, process, destination, and validation result

An accepted affected chain warrants urgent investigation. A rejected chain records an encounter that was blocked. Neither outcome alone establishes malicious activity; responders need destination, workload, and connection context.

This rule requires certificate-chain visibility from suitable TLS instrumentation or a TLS-aware proxy. Ordinary network-flow logs are insufficient. Passive network inspection cannot normally read the encrypted certificate portion of a TLS 1.3 handshake.

Root Certificates in the Trust Path

Finding one of these roots in a trust store is an exposure-assessment lead, not evidence of compromise. A store is exposed if it trusts one of these roots and does not separately block the affected intermediates.