eMudhra: eight intermediate CA keys trivially recoverable (P-384, values below 256); browsers, Go, Apple, Microsoft block them

Linha do tempo

1. securityweek.com ↗ · pub. 21/10/2026 08:22 · coletado 21/10 09:00

   Browsers and Trust Stores Block Eight eMudhra Intermediate CAs After Weak Key Generation Exposes Private Keys

   ler a análise desta fonte ocultar

   Eight intermediate certificates issued in April 2025 by Indian certificate authority eMudhra were found to have private keys that can be recovered from the certificates themselves. Anyone can use them to forge trusted HTTPS certificates and impersonate any website against clients that still trust these CAs. Mozilla and Google blocked the intermediates in Firefox and Chrome on October 17. Apple followed on October 19 and Microsoft on October 20. Sectigo took revocation steps and Cloudflare patched its services. Certificate Transparency logs show no evidence of malicious use before revocation, but not all clients enforce CT, so impersonation cannot be ruled out.

   Technical Details

   • The keys were generated with insufficient entropy. Mozilla's Dennis Jackson said they are effectively all zeroes apart from the last byte and can be recovered almost instantly with the baby-step giant-step discrete log algorithm. Several individuals have independently retrieved them.
   • According to eMudhra, a flaw in the script used in the key generation ceremony created a second, weaker key pair. That pair was mistakenly used for the certificate signing requests because its labels resembled those of the original keys.
   • The issuers were meant for export to US and European data centers to address data sovereignty needs. Only one reportedly entered production.
   • eMudhra cites human errors at multiple steps that broke key lifecycle integrity.

   Remediation

   • Apply browser, OS and trust-store updates so clients no longer trust the compromised intermediates. Some clients need software updates for this.
   • Use the tool published by Dennis Jackson to check whether a client still trusts the affected certificates.
   • eMudhra has revoked the certificates and says it will re-verify every key ceremony it has run.
2. gbhackers.com ↗ · pub. 21/10/2026 01:55 · coletado 21/10 02:00

   eMudhra CA key-generation flaw exposes eight weak P-384 intermediate private keys, prompting emergency distrust

   ler a análise desta fonte ocultar

   Researchers found that the private keys of eight eMudhra intermediate CA certificates could be recovered from public certificate data. Each P-384 key was an integer below 256, so near-instant recovery by simple enumeration or a discrete logarithm algorithm was possible. The incident was disclosed on October 20, 2026, and Mozilla, Google, Apple and Microsoft blocked the affected intermediates. Mozilla also requested an emergency distrust of the emSign ECC Root CA – G3. The article reports no Certificate Transparency evidence of exploitation against CT-enforcing browsers, but abuse against non-browser clients is unknown.

   Technical Details

   • Affected: six TLS intermediates trusted by major root programs and two code signing intermediates trusted by Microsoft, all in eMudhra's G3B and G3C series. Sectigo cross-signs containing the same public keys were also revoked.
   • Mozilla's Dennis Jackson reported that all eight P-384 keys were below 256, so the encoded values were nearly zero except for the final byte.
   • The keys were generated at a ceremony on April 30, 2025. Researcher Wayne proved control of the keys by signing the message "We have a problem here – Wayne" with each one and notified root programs on October 17. Mozilla independently recovered the keys that evening.
   • eMudhra's preliminary findings: a modified key-generation script added a wrap/unwrap test for exportable keys. Strong keys were created in HSMs, but flawed code also produced weak alternatives. Similar labels led staff to select the weak keys when creating CSRs. Earlier invalid CRL signatures were linked to this mismatch, and the CRLs were later signed with the compromised keys. eMudhra cited multiple human errors, and its investigation is ongoing.
   • Timeline: Firefox and Chrome blocked the intermediates on October 17, Apple on October 19 and Microsoft on October 20. eMudhra revoked the eight certificates on October 18, followed by Sectigo's cross-signs.
   • eMudhra halted issuance under the emSign ECC Root CA – G3 and estimates about 30,000 certificates need migration, 97% of them issued via ACME.

   Remediation

   • Update browsers, operating systems, development runtimes and certificate bundles. Recommended versions: NSS 3.131.1, Python certifi 2026.10.19 and pip 26.2.2.
   • Assess bundled trust stores separately, since browser protection does not cover command-line tools or applications that ship their own CA bundles.
   • Clients without effective revocation checking may remain exposed until their software or trust stores are updated.
   • Plan migration of certificates issued under the emSign ECC Root CA – G3.
3. bleepingcomputer.com ↗ · pub. 20/10/2026 21:46 · coletado 20/10 22:00

   eMudhra revokes eight CA intermediates with trivially recoverable P-384 keys; Mozilla, Google and Apple block them

   ler a análise desta fonte ocultar

   Certificate authority eMudhra revoked eight intermediate certificates after a researcher known as Wayne found on October 17 that their P-384 private keys were so weak that anyone could recover them almost instantly. The keys, generated in April 2025, had values below 256, so an attacker could recover them by testing 256 candidates. This would let an attacker forge trusted certificates for legitimate websites and intercept encrypted traffic. eMudhra says most of the intermediates were never used in production and it found no evidence of issuance to end users, and there is no evidence of abuse. Mozilla, Google and Apple have blocked the certificates, but software with its own certificate stores or no revocation checking may still trust them.

   Technical Details

   • All eight certificates used P-384 private keys generated in April 2025 with values smaller than 256.
   • Researcher Flüpke published one compromised key on GitHub. The key for "EM OV TLS CA - G3C" had a value of 4. BleepingComputer verified that it matches one of the revoked certificates.
   • eMudhra blamed an error in a certificate generation script. The error produced a second set of weaker keys, which were mistakenly selected for signing because their labels resembled those of the properly generated keys.
   • Some of the certificates were submitted to Sectigo for cross-signing.
   • Attackers could have recovered and abused the keys since April 2025, though no abuse has been observed.
   • Mozilla blocked the certificates via OneCRL on October 17, and Chrome blocked the six TLS-capable intermediates the same day. Apple added protections on October 19.
   • Mozilla released Firefox 158.0.1 and ESR updates on October 20. The Go team released 1.27.3 and 1.26.10 for CVE-2026-111943.
   • macOS's built-in /usr/bin/curl may continue to trust the certificates because its certificate bundle does not check revocation.

   Remediation

   • Install available updates for browsers, Go and other software that bundles its own certificate stores.
   • Check systems with the test endpoints and mitigation instructions in the advisory published by Mozilla engineer Dennis Jackson.
   • Review software that does not check revocation, including macOS /usr/bin/curl, and apply mitigations.
   • eMudhra revoked the eight certificates and stopped issuing new certificates under its G3 root.
4. blog.cloudflare.com ↗ · pub. 20/10/2026 19:20 · coletado 20/10 20:00

   Private keys of eight eMudhra intermediate certificates compromised, enabling forged TLS certificates for any domain

   ler a análise desta fonte ocultar

   On October 19, 2026, Cloudflare learned that the private keys of eight eMudhra intermediate certificates had been compromised. The certificates were widely trusted by browsers, operating systems and Cloudflare itself. Because the keys are weak, an attacker could forge a certificate for any domain and impersonate servers to intercept or modify traffic. Cloudflare patched critical services ahead of public disclosure and reports no active exploitation on its services. Customers must still update client software, trust stores and origin configurations.

   Technical Details

   • The issue is a weakness in certificate-based authentication in the WebPKI, not in TLS encryption algorithms.
   • Cloudflare prioritized services that use public certificates to authenticate remote endpoints, such as proxies connecting to origins and applications calling external APIs. It also updated shared trust stores and base images, and deployed the reloads, restarts and image deployments needed to activate them.
   • Applications with bundled or custom trust stores need separate assessment. An SDK update alone may not change the underlying verification policy, because API clients may delegate to an HTTP library, a language runtime, the OS or a custom trust configuration.
   • Browsers could mitigate quickly through revocation mechanisms such as Chrome CRLSets, which most other software stacks lack.
   • Mozilla's Dennis Jackson crowdsourced a list of patched packages and runs a test site covering browser and non-browser verification paths.

   Remediation

   • Upgrade Cloudflare One Client to v2.5.6 (Android), v1.12.16 (iOS), and 2026.8.2115.0 (Windows, macOS, Linux). The iOS Cloudflare One Agent update is still pending app review.
   • Upgrade the 1.1.1.1 app to v6.38.10 (Android), v6.31.7 (iOS), and 2026.8.2115.0 (Windows, macOS, Linux).
   • Update cloudflared (Cloudflare Tunnel). Customers on Cloudflare Zero Trust Gateway with an up-to-date client are automatically protected.
   • Review Cloudflare Containers and Sandboxes images and dependencies for affected trust stores, or enable HTTPS egress interception.
   • Update dependencies (including indirect ones), rebuild images, and reload, restart or redeploy applications. Validate through each application's actual TLS path.
   • Do not resolve resulting certificate errors by disabling verification.
5. darkreading.com ↗ · pub. 20/10/2026 18:45 · coletado 20/10 20:00 só resumo do feed

   Google, Mozilla, Apple and Go project block eMudhra certificates tied to 8 compromised keys

   ler a análise desta fonte ocultar

   Google, Mozilla, Apple, the Go project and other organizations moved quickly to block certificates issued by the Indian certificate authority eMudhra. The certificates are tied to 8 compromised keys. It is unclear how the keys were compromised. The source text available is limited to the headline and a short summary, so the scope of the affected certificates and any abuse are not stated.

   Technical Details

   • Eight keys associated with eMudhra certificates were compromised; the method of compromise has not been established.
   • Trust-store operators blocked the affected certificates, limiting their usability for TLS and other trust decisions.
   • No CVEs, IOCs, threat actors or confirmed abuse are named in the available text.

   Remediation

   • Ensure browsers, operating systems and Go toolchains are updated so the distrust and block entries apply.
   • Inventory any certificates issued by eMudhra in your environment and plan for reissuance from a trusted CA if they are affected.
6. theregister.com ↗ · pub. 20/10/2026 19:57 · coletado 20/10 20:00

   eMudhra CA private keys compromised: eight intermediate certificates used trivially guessable keys, including the number 4

   ler a análise desta fonte ocultar

   Mozilla received a report on 17 October 2026 that private keys for eight eMudhra intermediate certificates were compromised. The Indian certification authority says it has issued over 60 million certificates. Researchers found some of the keys were trivially small integers, so anyone could forge HTTPS certificates for arbitrary domains and impersonate servers or intercept and modify traffic. Mozilla, Chrome and Apple have moved to distrust the affected certificates, though only once users install updates. eMudhra has revoked the certificates, but certificates signed with these keys are still in circulation. The article does not report exploitation in the wild, and eMudhra had not responded to The Register's questions.

   Technical Details

   • The report reached Mozilla on Saturday 17 October at 20:06 UTC, from a community member. Dennis Jackson of Mozilla's cryptography engineering team published the disclosure.
   • Researcher Scott Helme recovered the private keys from the public certificates in under a second. One key is the number 4, others are 56 and 115. Other researchers found 66, 155, 156, 230 and 237.
   • A P-384 private key should be a random 384-bit number, roughly 2^384 possibilities. These keys are trivially guessable, so any certificate issued under them is open to forgery.
   • Cloudflare noted that an attacker can create a forged certificate for any domain.
   • Several FOSS projects have released updates that stop trusting eMudhra certificates.

   Remediation

   • Update browsers and operating systems to versions that distrust the eMudhra intermediates (Mozilla, Chrome, Apple).
   • Inventory environments, including non-browser clients, services and embedded systems, for reliance on certificates chained to eMudhra, since these clients may not detect or reject the bad certificates.
   • Apply updates from FOSS projects that remove trust in the eMudhra certificates.
   • Replace affected certificates with ones from another CA and remove the eMudhra roots and intermediates from trust stores where feasible.
7. thehackernews.com ↗ · pub. 20/10/2026 14:09 · coletado 20/10 16:00

   Eight eMudhra intermediate CA private keys compromised; browsers, Go and trust stores ship emergency blocks

   ler a análise desta fonte ocultar

   Mozilla and the Chrome Root Program confirmed on October 20 that the private keys of eight eMudhra intermediate CA certificates (emSign brand) are compromised. Anyone holding these keys could issue certificates for any website that a browser would accept. A researcher credited as "Wayne" reported the compromise on October 17, and Chrome and Firefox blocked the certificates within hours. How and when the keys left eMudhra, and whether anyone besides the researcher holds them, is unknown. Chrome states that no TLS certificate chaining to the six web intermediates had been logged to Certificate Transparency before its block, so none would have been trusted by default in Chrome.

   Technical Details

   • Affected certificates: EM DV, OV and EV TLS CA - G3B (eMudhra BV, Netherlands) and G3C (eMudhra Inc, US), plus EM OV CS CA - G3B and G3C for code signing.
   • The six TLS intermediates were issued by emSign Root TLS CA - G3 and chain to emSign ECC Root CA - G3, a root in the Chrome and Apple stores and, until October 20, in Mozilla's.
   • Each of the eight also exists as a cross-signed copy by Sectigo (AAA Certificate Services root) with the same public key. Chrome and Firefox stopped trusting that Sectigo root for websites in April 2025, but Apple's iOS 26 and macOS 26 root list includes it.
   • Timeline: Chrome received the report at 18:05 UTC on October 17 and had a CRLSet block in place by 19:45 UTC. Mozilla received it at 20:06 UTC and completed a OneCRL push at 22:59 UTC. Apple blocked the certificates on October 19 and Microsoft on October 20. eMudhra has revoked all eight.
   • Chrome's block matches the public key, so it also covers the Sectigo cross-signed copies. Chrome did not need to block the two code-signing certificates because its TLS verifier will not build a path through a code-signing-only intermediate.
   • Go blocked the eight keys in its October 20 security releases on its URGENT track, without naming the CA. The filter lives in the standard library and has no opt-out; programs must be rebuilt, and Go 1.25 and older get no fixes.
   • certifi, webpki-roots and Homebrew ca-certificates removed emSign ECC Root CA - G3 from their bundles. Homebrew also removed Sectigo's AAA Certificate Services root and emSign Root TLS CA - G3. This also cuts off legitimate certificates chaining to those roots. Mozilla made the same change in NSS.
   • Software that does not check revocation (Go binaries, Python certifi users, many Linux root stores) keeps trusting the chains until code or bundles change.
   • Chrome found no other CAs with this failure mode, and Mozilla does not currently believe other CAs are affected. Chrome will remove emSign ECC Root CA - G3 in root store version 43 and is reviewing emSign Root CA - G1.
   • No method exists to detect past misuse beyond Chrome's CT search, which covers only logged certificates.

   Remediation

   • Mozilla's guidance: nothing is needed where clients reliably check revocation and fail closed.
   • Where software can block individual intermediates, block the eight now; otherwise consider removing trust in the roots that signed them.
   • Rebuild Go programs with the latest supported release, and update certifi, webpki-roots, Homebrew ca-certificates and NSS-based bundles.
   • Firefox installations need no action unless Remote Settings is disabled by policy or blocked; the October 20 releases carry the block list for them.
8. thehackernews.com ↗ · pub. 20/10/2026 08:32 · coletado 20/10 10:00 primeiro registro

   Go 1.27.3/1.26.10 emergency release blocks eight eMudhra intermediate CA keys over undisclosed security concerns

   ler a análise desta fonte ocultar

   On October 20, the Go team released Go 1.27.3 and Go 1.26.10 on its URGENT track. The certificate verifier now rejects any chain passing through one of eight intermediate CA keys, citing unspecified "specific security concerns around their operation." A commenter on the Go issue matched the SHA-256 key hashes to intermediates of the Indian CA eMudhra (emSign brand). Two days earlier, on October 17, Mozilla added six intermediates under emSign Root TLS CA - G3 to OneCRL. Neither Mozilla, Go nor eMudhra has said what prompted the actions, and the Mozilla bug is closed to the public. Whether Chrome, Apple or Microsoft have acted is not established.

   Technical Details

   • The filter hashes each certificate's public key, so cross-signed copies of the same key are also caught. It applies in Go's own verifier and in the macOS and Windows code paths that delegate verification to the OS.
   • Rejected chains return x509: no valid chains built. There is no setting to disable the filter, and it appears to apply even when a program supplies its own trusted roots, so private deployments trusting these keys will also fail. Go has not said whether this is intended.
   • By the commenter's matching, which The Hacker News did not independently verify, six keys are TLS intermediates (DV, OV and EV, G3B and G3C variants) under emSign Root TLS CA - G3, and two are code-signing intermediates (EM OV CS CA - G3B and G3C) under emSign Root CS CA - G3.
   • Go's verifier does no revocation checking and does not read browser block lists such as CRLSets, so blocking requires shipping a release. Programs keep the old behavior until rebuilt. Bluesky's indigo was rebuilt on October 20.
   • Go's policy reserves the URGENT track for threats to ecosystem integrity or actively exploited severe flaws. Go has not said which applied, and unlike its October 8 security releases, this one had no pre-announcement.
   • eMudhra's roots emSign Root CA - G1 and emSign ECC Root CA - G3 are in the Chrome, Apple and Mozilla root stores. The newer TLS root is cross-signed by G1, which is how it chains to a trusted root. A September public discussion on adding ten new eMudhra roots closed with no objections. eMudhra's repository had no notice and no public statement was found.

   Remediation

   • Upgrade to a supported Go release (1.27.3 or 1.26.10) and rebuild affected programs. Go 1.25 and older are unsupported and get no fix.
   • No workaround exists. Services whose certificates chain through the eight keys need certificates from a different intermediate before rebuilt Go clients can connect.
   • Check private deployments that intentionally trust these keys, as they will break.