EN PT-BR
← Voltar ao feed
high technology software_development certificate_authorities

eMudhra CA key compromise: eight intermediate CAs with trivially computable private keys enable forged TLS certificates

1 fonte(s) · 1 atualização(ões) · publicado 21/10/2026 21:00 · coletado há 1 hora

Eight eMudhra intermediate CAs, created on 30 April 2025, were generated with weak private keys (each a number below 256), so anyone can derive the keys from the public certificates and forge TLS or code-signing certificates. Six intermediates issue TLS certificates and two issue code signing certificates. Browsers block the intermediates, but many other TLS clients (CI runners, container images, JVMs, Go, Python, Rust and PHP CA bundle packages, Electron apps, macOS tools) still trust them and do not check revocation. Forged certificates for google.com and other domains have been in public CT logs since 19 October, and mitmproxy 12.3.0 can sign intercepted traffic with a recovered key. As of 21 October, no in-the-wild use against a client had been confirmed (per The Hacker News, as cited by SafeDep).

Entenda a falha

A vulnerabilidade

CVE-2026-111943 is the identifier projects use to track trust-store updates for eight eMudhra intermediate CAs created on 30 April 2025 with weak private keys. Each key is a number below 256, so anyone can compute it from the public certificate and forge TLS or code-signing certificates. Six intermediates issue TLS certificates and two issue code-signing certificates. A client is affected if it trusts emSign ECC Root CA - G3, emSign Root TLS CA - G3 or AAA Certificate Services, does not block the intermediates and does not check revocation. The attacker needs an on-path position. Fixes: Go 1.27.3/1.26.10, certifi 2026.10.19, webpki-roots 1.0.10, rustls-webpki 0.103.16 (0.102 and older get no fix), composer/ca-bundle 1.4.16, NSS 3.131.1.

Como funciona

A TLS client connects to a server and receives a certificate chain. The client validates the chain against the root certificates in its trust store. Each of the eight intermediates has two paths to a trusted root: the emSign path (via emSign Root TLS CA - G3 to emSign ECC Root CA - G3) and a Sectigo-signed copy chaining to AAA Certificate Services, giving 16 CA certificates with 8 keys. An attacker who intercepts traffic can present a leaf signed with a recovered intermediate key. The client accepts it because the chain leads to a trusted root and nothing tells it the intermediate is bad. Browsers reject it because vendors push blocklists (Chrome CRLSet, Firefox OneCRL). Most other clients read a CA bundle from disk and skip revocation checks.

Por que é vulnerável

The root cause is weak key generation. eMudhra says a flaw in its key generation script produced a second set of weak keys, and staff used the wrong set (Mozilla bug 2083449). Keys that are tiny numbers can be derived from the public certificate in under a second. The impact is widened because many clients trust the roots without blocking the intermediates or checking revocation. The remediation is distrusting or blocking the intermediates and removing the emSign ECC Root CA - G3 root from trust stores.

Onde está

The articles point to Mozilla bug 2083449 and NSS 3.131.1 (removal of emSign ECC Root CA - G3), not to a code file; the flaw lies in eMudhra's key generation script and the eight issued intermediates.

Como foi descoberta

On 17 October a researcher credited as Wayne sent proof of the weak keys to the browser vendors, and Chrome and Firefox blocked the intermediates the same day. On 18-19 October eMudhra and Sectigo revoked their certificates. Apple blocked them on 19 October and Microsoft on 20 October; Mozilla removed emSign ECC Root CA - G3 (NSS 3.131.1) on 20 October. Node.js shipped fixes and Red Hat published RHSB-2026-012 on 21 October. Chrome will remove the root on 27 October. As of 21 October, per The Hacker News, no in-the-wild use against a client was confirmed.

PoC pública

Forged certificates for google.com and other domains have been in public Certificate Transparency logs since 19 October. mitmproxy 12.3.0, released 22 October, can sign intercepted traffic with a recovered eMudhra key, so an attacker who can intercept an affected client's traffic needs no custom tooling. This is a working, practical capability, not just a verification. A community tracker also hosts test hosts serving forged certificates for defensive probing. Patching and trust-store updates are urgent for clients that skip revocation checks.

Publicada em: safedep.io/blog/emudhra-ca-key-compromise ↗

Explicação gerada por IA a partir da matéria e dos artigos, em 02/11/2026 05:16.

Detalhes técnicos

  • eMudhra says a flaw in its key generation script produced a second set of weak keys and staff used the wrong set (Mozilla bug 2083449).
  • Each intermediate has two trust paths: the emSign path (leaf -> intermediate -> emSign Root TLS CA - G3 -> emSign ECC Root CA - G3) and a Sectigo-signed copy chaining to AAA Certificate Services. This gives 16 CA certificates with 8 keys.
  • Affected intermediates: EM DV/OV/EV TLS CA - G3B and G3C, EM OV CS CA - G3B and G3C.
  • A client is affected if it trusts emSign ECC Root CA - G3, emSign Root TLS CA - G3 or AAA Certificate Services, does not block the intermediates, and does not check revocation. Mozilla-derived stores (Debian, Ubuntu, Alpine, certifi, Node.js) lack AAA Certificate Services. Windows, macOS, older Linux and some JDKs contain it.
  • Exploitation requires an on-path position (hostile Wi-Fi, compromised router, DNS/BGP hijack, shared self-hosted runner network).
  • Timeline: 17 Oct researcher "Wayne" reported the weak keys and Chrome and Firefox blocked the intermediates; 18-19 Oct eMudhra and Sectigo revoked the certificates; 19 Oct Apple blocked them and Go 1.27.3/1.26.10 shipped; 20 Oct Microsoft blocked them and Mozilla removed emSign ECC Root CA - G3 (NSS 3.131.1); 21 Oct Node.js fixes and Red Hat RHSB-2026-012; Chrome will remove the root on 27 Oct. Projects track the trust store updates as CVE-2026-111943.
  • The guide provides probes (curl, Python, Node.js, Go, Java, PHP) against the tracker hosts, an offline SHA-256 fingerprint scan script for PEM bundles and images, and a vet policy for lockfiles.
  • Patched versions include certifi 2026.10.19, webpki-roots and webpki-root-certs 1.0.10, rustls-webpki 0.103.16, composer/ca-bundle 1.4.16, castore 1.0.22 and Alpine ca-certificates-bundle 20261020-r0. rustls-webpki 0.102 and older get no fix.
  • SafeDep found the eclipse-temurin:21-jre image (Ubuntu 26.04) still trusted emSign ECC Root CA - G3.

Remediação

  • Replace any server certificate chaining to emSign ECC Root CA - G3.
  • Probe each CI runner type and each TLS inspection proxy.
  • Scan and rebuild container images with updated trust stores, and redeploy.
  • Rebuild Go binaries with Go 1.27.3 or 1.26.10, upgrade the JDK or add the blocked.certs entries and restart, upgrade Node.js and restart processes.
  • Update CA bundle packages in lockfiles and fix developer laptops (mainly macOS).
  • Check Windows code-signature verification and search proxy logs for the intermediates.
  • Decide whether to rotate credentials and notify affected teams and vendors.

Linha do tempo

  1. safedep.io ↗ · pub. 21/10/2026 21:00 · coletado 02/11 05:00 primeiro registro

    eMudhra CA key compromise: eight intermediate CAs with trivially computable private keys enable forged TLS certificates

    ler a análise desta fonte

    Eight eMudhra intermediate CAs, created on 30 April 2025, were generated with weak private keys (each a number below 256), so anyone can derive the keys from the public certificates and forge TLS or code-signing certificates. Six intermediates issue TLS certificates and two issue code signing certificates. Browsers block the intermediates, but many other TLS clients (CI runners, container images, JVMs, Go, Python, Rust and PHP CA bundle packages, Electron apps, macOS tools) still trust them and do not check revocation. Forged certificates for google.com and other domains have been in public CT logs since 19 October, and mitmproxy 12.3.0 can sign intercepted traffic with a recovered key. As of 21 October, no in-the-wild use against a client had been confirmed (per The Hacker News, as cited by SafeDep).

    Technical Details

    • eMudhra says a flaw in its key generation script produced a second set of weak keys and staff used the wrong set (Mozilla bug 2083449).
    • Each intermediate has two trust paths: the emSign path (leaf -> intermediate -> emSign Root TLS CA - G3 -> emSign ECC Root CA - G3) and a Sectigo-signed copy chaining to AAA Certificate Services. This gives 16 CA certificates with 8 keys.
    • Affected intermediates: EM DV/OV/EV TLS CA - G3B and G3C, EM OV CS CA - G3B and G3C.
    • A client is affected if it trusts emSign ECC Root CA - G3, emSign Root TLS CA - G3 or AAA Certificate Services, does not block the intermediates, and does not check revocation. Mozilla-derived stores (Debian, Ubuntu, Alpine, certifi, Node.js) lack AAA Certificate Services. Windows, macOS, older Linux and some JDKs contain it.
    • Exploitation requires an on-path position (hostile Wi-Fi, compromised router, DNS/BGP hijack, shared self-hosted runner network).
    • Timeline: 17 Oct researcher "Wayne" reported the weak keys and Chrome and Firefox blocked the intermediates; 18-19 Oct eMudhra and Sectigo revoked the certificates; 19 Oct Apple blocked them and Go 1.27.3/1.26.10 shipped; 20 Oct Microsoft blocked them and Mozilla removed emSign ECC Root CA - G3 (NSS 3.131.1); 21 Oct Node.js fixes and Red Hat RHSB-2026-012; Chrome will remove the root on 27 Oct. Projects track the trust store updates as CVE-2026-111943.
    • The guide provides probes (curl, Python, Node.js, Go, Java, PHP) against the tracker hosts, an offline SHA-256 fingerprint scan script for PEM bundles and images, and a vet policy for lockfiles.
    • Patched versions include certifi 2026.10.19, webpki-roots and webpki-root-certs 1.0.10, rustls-webpki 0.103.16, composer/ca-bundle 1.4.16, castore 1.0.22 and Alpine ca-certificates-bundle 20261020-r0. rustls-webpki 0.102 and older get no fix.
    • SafeDep found the eclipse-temurin:21-jre image (Ubuntu 26.04) still trusted emSign ECC Root CA - G3.

    Remediation

    • Replace any server certificate chaining to emSign ECC Root CA - G3.
    • Probe each CI runner type and each TLS inspection proxy.
    • Scan and rebuild container images with updated trust stores, and redeploy.
    • Rebuild Go binaries with Go 1.27.3 or 1.26.10, upgrade the JDK or add the blocked.certs entries and restart, upgrade Node.js and restart processes.
    • Update CA bundle packages in lockfiles and fix developer laptops (mainly macOS).
    • Check Windows code-signature verification and search proxy logs for the intermediates.
    • Decide whether to rotate credentials and notify affected teams and vendors.