eMudhra exits SSL/TLS business after eight intermediate CA keys found trivially weak; Mozilla and Chrome distrust ECC root

Linha do tempo

1. thehackernews.com ↗ · pub. 22/10/2026 15:12 · coletado 22/10 16:00

   eMudhra exits global SSL/TLS business after 8 intermediate CA private keys found trivially guessable; Chrome and Firefox distrust ECC root

   ler a análise desta fonte ocultar

   Indian certificate authority eMudhra will withdraw from its global SSL/TLS certificate business, its board decided on Thursday, five days after a researcher reported recovering the private keys of eight of its intermediate CA certificates. Six of the eight were TLS intermediates. Mozilla decided on October 20 to distrust the root above them, emSign ECC Root CA - G3, in Firefox, and Chrome is expected to follow on the morning of October 27 (Pacific time). About 30,800 unexpired certificates chain to that root, 99.9% of them issued through InCommon (Internet2's higher-education certificate service, which moved onto eMudhra's CertiNext platform between April and July 2026). eMudhra says its systems were not breached and that it never used the eight CAs to issue certificates to websites or users.

   Technical Details

   • The researcher reported the weak keys to Apple, Google, Microsoft, Mozilla and eMudhra on October 17. Each private key should have been a huge random number, but all eight were below 256, so they could be derived almost instantly.
   • Chrome and Firefox blocked the six TLS intermediates within hours. Google says no website certificate from them appeared in Certificate Transparency logs before the block, so none could have been used against Chrome or other software that requires CT logging.
   • eMudhra's G1 RSA hierarchy (emSign Root CA - G1) is separate from the ECC root. Mozilla is not removing it for now, and Chrome is still deciding whether to keep eMudhra's remaining CA certificates in its root store.
   • On October 14, eMudhra published a CRL for emSign Root TLS CA - G1 whose signature does not verify against that CA's own key. A bug report participant suggests it was signed with the key of an eMudhra OCSP certificate, i.e. the wrong signing key rather than another weak key.
   • In 2025, eMudhra published invalid CRLs for six of the same intermediates and said it fixed them by regenerating the CRLs with the appropriate keys. On October 19 it told Mozilla that the lists had been "resigned with flawed keys", the weak keys found this month. Chrome said this raises "serious concerns regarding eMudhra's transparency and incident handling" and asked why the 2025 report omitted that two key pairs existed per CA.
   • Chrome posted 12 questions to the bug report on October 21. As of 13:31 UTC on October 22, eMudhra had not answered them publicly; its last comment was on October 20.
   • About 30,000 certificates need to be moved, about 97% issued via ACME. Standard ACME clients do not replace certificates outside their renewal window unless they support ACME Renewal Information (ARI) or an operator intervenes manually. Moving from ECC to RSA may also require client configuration changes.

   Remediation

   • Google instructs operators with certificates under the ECC root to immediately acquire and install a new TLS certificate from another PKI hierarchy in the Chrome Root Store.
   • Cornell tells holders to request RSA certificates, which chain to eMudhra's unaffected G1 root, but the University of Michigan warns that root could also become distrusted and names Let's Encrypt as its main alternative.
   • eMudhra will replace affected customers' certificates with free ones from unnamed partners and will keep revocation and status services running until all SSL/TLS certificates it issued have expired or been replaced. Its other businesses, including digital signature certificates, eSign and CertiNext, continue.
2. unit42.paloaltonetworks.com ↗ · pub. 22/10/2026 14:15 · coletado 22/10 15:00

   eMudhra Intermediate CA Private Keys Compromised via Weak Randomness; Eight Certificates Revoked

   ler a análise desta fonte ocultar

   Eight intermediate CA private keys belonging to Indian certificate authority eMudhra Limited were compromised because of a cryptographic defect in certificate generation. The keys were generated with insufficient randomness, so an attacker could derive the private keys from the public certificates. This would let third parties sign unauthorized public TLS certificates and run meddler-in-the-middle (MitM) interception, impersonation or session hijacking against targeted domains. eMudhra has revoked the eight certificates, and major browser and OS vendors have moved to revoke or untrust the intermediates. The article does not report in-the-wild abuse.

   Technical Details

   • Root cause: low-entropy private key generation for the intermediate CAs. The keys are derivable from the public certificates.
   • Impact: rogue certificates trusted by clients that still honor the affected chains, enabling MitM, impersonation and session hijacking.
   • Tracking references: Mozilla Bugzilla bug 2083449 (private key compromise of intermediate certificates) and a Google Security notice on the compromised eMudhra intermediates.

   Remediation

   • Discovery: inventory public and internal services whose TLS certificates chain to eMudhra intermediates. Check code repositories, build pipelines, containers and custom trust stores (Linux /etc/ssl/certs, Java keystores, Python certifi, Docker base images, mobile app bundles) for bundled eMudhra roots or intermediates.
   • Containment: revoke and reissue affected certificates from another trusted CA. Push trust store updates through MDM to distrust the intermediates. Enforce strict CRL/OCSP checking on proxies, gateways and egress controls.
   • Hunting: review network, proxy and DNS logs for connections to unknown external IPs using eMudhra-signed certificates. Look for spikes in TLS handshake failures or untrusted issuer warnings. Review SSO, VPN and cloud portal authentication logs for intercepted or replayed sessions.
   • Hardening: monitor Certificate Transparency logs for your domains, enforce CAA records, and move to automated certificate lifecycle management with short-lived certificates.
3. theregister.com ↗ · pub. 22/10/2026 13:58 · coletado 22/10 15:00

   eMudhra exits global SSL/TLS issuance after eight intermediate CA private keys were found to be trivially weak, one being the number 4

   ler a análise desta fonte ocultar

   Indian certification authority eMudhra announced on 22 October 2026 that it is withdrawing from the global SSL/TLS certificate business. The announcement follows public reports that the private keys of eight intermediate CAs were trivially weak. The issue was reported to Mozilla on 17 October. The key values were 4, 56, 66, 115, 155, 156, 230 and 237. eMudhra says the exit is driven by cost, competition and the scrutiny it attracted, and that SSL/TLS is about 1% of its revenue. It maintains that the affected CAs issued no end-entity certificates, were revoked within 14 hours of discovery, and that its infrastructure and data were not compromised.

   Technical Details

   • The weak keys belonged to eight intermediate CAs. Anyone could recover them, so an attacker could in theory forge certificates trusted by systems that had not blocked those CAs.
   • eMudhra attributes the failure to a flaw in the key generation ceremony: a wrap/unwrap step produced a second set of weak keys alongside the intended strong ones. The weak keys were the ones published to the browser root stores.
   • The infrastructure had undergone two years of independent audits and had been in browser trust lists since mid-2025. This raises questions about why the weak keys were not caught earlier.

   Remediation

   • The affected CAs have been revoked.
   • eMudhra will publish a root-cause report and fulfil its remaining commitments to browser root programs while winding down.
   • It will keep serving the G1 RSA roots until customers are moved to other certificate issuers free of charge. Revocation and status services will run until every issued certificate has expired or been replaced.
4. cyberscoop.com ↗ · pub. 22/10/2026 11:57 · coletado 22/10 13:00

   eMudhra exits SSL/TLS certificate business after researchers recover weak private keys of eight intermediate CA certificates

   ler a análise desta fonte ocultar

   Indian certificate authority eMudhra announced it will stop issuing SSL/TLS certificates, days after researchers showed that the private keys of eight of its intermediate certificates could be reconstructed in under a second. Major browser vendors blocked the certificates, Mozilla removed the eMudhra root from its trust store, and Google plans to remove the root from Chrome while it reviews the company's remaining root. eMudhra attributes the flaw to an error in an April 2025 key generation ceremony. It says its infrastructure was not compromised, no data was breached and none of the eight intermediates issued end-entity certificates. CERT-In reported no malicious use of the keys as of Wednesday, though actual use is unknown. The company's shares fell 40% in the two days after disclosure.

   Technical Details

   • A researcher notified Apple, Google, Microsoft and Mozilla that the private keys of eight eMudhra intermediate certificates could be computed from the public certificates because they were generated with too little randomness.
   • Security researcher Scott Helme recovered all eight keys on his laptop in under a second. He said an AI agent later repeated the task from a single prompt.
   • Each key was a whole number below 256, and one was simply logged as the number 4. A normal key of this type is roughly 77-78 digits long.
   • Because a certificate publicly displays the key it was built from, anyone could test every possible value and then forge certificates and impersonate websites.
   • eMudhra says the error in the April 2025 key ceremony produced a second, weak set of keys that was published to browser trust lists instead of the intended ones.
   • Chrome and Firefox blocked the certificates within hours of the report. Apple blocked them Monday and Microsoft on Tuesday. Go, Node.js, Python's certifi bundle and several Linux distributions also shipped updates.

   Remediation

   • Apply the latest browser, OS and runtime updates and trust store bundles (Go, Node.js, Python certifi, Linux distributions) that distrust the affected eMudhra certificates.
   • Review any use of eMudhra-issued SSL/TLS certificates and plan migration to another certificate authority, since eMudhra is ending issuance.
5. aikido.dev ↗ · pub. 22/10/2026 08:53 · coletado 22/10 10:00

   eMudhra CA compromise: eight intermediate CA private keys trivially guessable (one is the number 4), non-browser clients still trust them

   ler a análise desta fonte ocultar

   eMudhra, an India-based certificate authority trusted by major root programs, generated the private keys of eight intermediate CA certificates (issued April 2025) so poorly that each key is below 256, and one is the number 4. A researcher known as Wayne reported the compromise to the root programs on 17 October 2026, proving it by signing the message "We have a problem here" with all eight keys. Anyone holding such a key can sign valid certificates for any domain, but abusing a forged certificate still requires a network-path position (e.g. hostile Wi-Fi or a compromised router). Browsers and operating systems have blocked the certificates (Firefox and Chrome from 17 Oct, Apple from 19 Oct, Microsoft from 20 Oct), but tools that do not check revocation (curl, git, Python, containers, language runtimes, IoT) may still trust them until their CA bundles are updated. The article states that it is unknown whether attackers used the flawed keys.

   Technical Details

   • The eight intermediates chain up to emSign ECC Root CA - G3, which Mozilla has removed from its trust store; Chrome is expected to follow on 27 October. Six intermediates were for TLS and two were Microsoft-trusted code-signing CAs, so malware could also be signed under any publisher name.
   • A properly generated key is chosen from about 10^115 values; these needed at most 256 guesses. Suggested causes (not confirmed): a type-casting bug truncating the random number to a byte, or old Go behaviour truncating a decimal conversion to a single byte.
   • Browsers receive revocation through OneCRL, CRLite and CRLSets. eMudhra also revoked the certificates, but only clients that check revocation see this. Most CLI tools and runtimes do not and need a new trust list.
   • Exposed: macOS built-in curl, git, python3, perl, ruby and openssl (read /etc/ssl/cert.pem, not yet updated by Apple); Linux tools relying on the distribution ca-certificates package; Docker images that froze the old bundle (as of 22 Oct, grafana/grafana:latest, mysql:latest, jenkins/jenkins:latest and bitnami/postgresql:latest were cited); Go, Java, Node.js, Python certifi (before 2026.10.18) and Rust webpki-roots; IoT firmware.
   • The intermediates did not appear in certificate transparency logs before the block, so clients enforcing CT (Firefox, Chrome, Edge, Safari) could not have been attacked. Clients not enforcing CT could have been targeted.

   Remediation

   • Update the OS and browsers, and update the CA bundle on servers and in images. Patched ca-certificates versions cited: Ubuntu 20260816ubuntu0.*, Debian 12 20250419~deb12u2, Alpine 20261020-r0, Fedora 2026.2.92_v9.0.319. Check the incident site table for your distribution and runtime, and regenerate the trust store where required.
   • Rebuild images with a fresh base (docker build --pull --no-cache) and restart services; running containers keep the old bundle.
   • Test with curl against dv-g3b-emudhra.we-have-a-problem.com and dv-g3b-aaa-emudhra.we-have-a-problem.com: an SSL failure with HTTP 000 is the desired result, HTTP 200 means the client still trusts the intermediates.
   • Use the incident site's workaround commands for macOS built-in tools and update bundled runtimes (Node.js, Go, Java, certifi) once patched releases are available.
6. theregister.com ↗ · pub. 22/10/2026 03:38 · coletado 22/10 04:00

   eMudhra attributes weak CA private keys to a flawed key generation ceremony and points to its audits

   ler a análise desta fonte ocultar

   Indian certification authority eMudhra has publicly responded to the disclosure that private keys behind some of its root and issuing CAs were trivially weak. One key was reportedly the number "4" and others were short, easily guessed numbers. The company says a flaw in a Key Generation Ceremony (KGC) held on April 30, 2025 produced a second set of weak keys alongside the intended strong ones, and the weak set was the one published to browser root stores. Because the keys can be deduced, attackers could forge certificates and impersonate websites or other resources. eMudhra notes its roots passed independent audits for two years and have been in browser trust lists since mid-2025, which appears to shift some blame to auditors and other stakeholders. It says TLS is about 1% of revenue. It is giving affected customers replacement certificates and working with root programs while its root-cause investigation continues.

   Technical Details

   • KGC held on April 30, 2025 using FIPS 140-2 Level 3 HSMs.
   • According to eMudhra, a flaw in a wrap/unwrap step produced a second set of weak keys next to the original strong keys; the weak keys were published to the browser root stores.
   • Root cause is not yet established, per the company.
   • The article does not report in-the-wild exploitation or forged certificates.

   Remediation

   • eMudhra is issuing replacement certificates to affected customers and coordinating with browser root programs.
   • Organizations relying on eMudhra-issued certificates should identify affected certificates and replace them, and track root program decisions on trust removal.
7. safedep.io ↗ · pub. 21/10/2026 21:00 · coletado 22/10 02:00

   eMudhra weak intermediate CA keys: developer response guide, probes and patched versions for clients that still trust them

   SafeDep adds a practical defender guide: the dual emSign/Sectigo chain structure (16 certificates, 8 keys), which trust stores are affected, test hosts, probes and an offline fingerprint scanner, a patched-version table, Node.js fixes and Red Hat RHSB-2026-012 on 21 October, mitmproxy 12.3.0 with ready-made eMudhra signing, and a report of forged certificates for google.com in public CT logs since 19 October. It also dates the Go release to 19 October rather than 20 October.

   ler a análise desta fonte ocultar

   SafeDep adds a practical defender guide: the dual emSign/Sectigo chain structure (16 certificates, 8 keys), which trust stores are affected, test hosts, probes and an offline fingerprint scanner, a patched-version table, Node.js fixes and Red Hat RHSB-2026-012 on 21 October, mitmproxy 12.3.0 with ready-made eMudhra signing, and a report of forged certificates for google.com in public CT logs since 19 October. It also dates the Go release to 19 October rather than 20 October.

   Private keys of eight eMudhra intermediate CAs, created on 30 April 2025, are numbers below 256 and can be computed from the public certificates in under a second. They allow forged TLS certificates for any domain and forged code-signing certificates. Browsers already block the intermediates, but many other TLS clients (CI runners, container images, JVMs, Go binaries, Python/Rust/PHP CA bundle packages, Electron apps, macOS built-in tools) still trust them because they do not check revocation. SafeDep published a response guide with probes, an offline scanner, a patched-version table and a vet policy. It reports forged certificates for google.com and other domains in public CT logs since 19 October (ctlogs.dev), while no confirmed attack on a client had been reported as of 21 October (The Hacker News). mitmproxy 12.3.0 (22 October) can already sign intercepted traffic with a recovered eMudhra key.

   Technical Details

   • Eight intermediates: six TLS (EM DV/OV/EV TLS CA - G3B and G3C) and two code signing (EM OV CS CA - G3B and G3C). eMudhra attributes it to a flaw in its key generation script that produced a second set of weak keys, with staff using the wrong set (Mozilla bug 2083449).
   • Each intermediate has two paths: the emSign path (leaf -> intermediate -> emSign Root TLS CA - G3 -> emSign ECC Root CA - G3) and the Sectigo path (a Sectigo-signed copy chaining to AAA Certificate Services, May 2025). That gives 16 CA certificates with 8 keys.
   • 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 16 intermediates and does not check revocation. Mozilla-derived stores (Debian, Ubuntu, Alpine, certifi, Node.js) do not contain AAA Certificate Services; Windows, macOS, older Linux and some JDK builds do.
   • Exploitation needs a forged certificate plus an interception position (hostile Wi-Fi, compromised router, DNS/BGP hijack, shared self-hosted runner network). mitmproxy --emudhra (emSign path) and --emudhra-old (Sectigo path) remove the need for custom tooling.
   • Timeline: 17 Oct Wayne reports, Chrome and Firefox block; 18-19 Oct eMudhra and Sectigo revoke; 19 Oct Apple blocks, Go 1.27.3/1.26.10; 20 Oct Microsoft blocks, Mozilla removes emSign ECC Root CA - G3 (NSS 3.131.1); 21 Oct Node.js fixes, Red Hat RHSB-2026-012, CVE-2026-111943 used to track trust store updates; Chrome removes the root on 27 Oct.
   • Probes (curl, Python, Node.js, Go, Java, PHP) connect to tracker hosts serving forged chains; both the emSign and Sectigo hosts must give NOT AFFECTED. A SHA-256 fingerprint scanner (emudhra-scan.sh) finds PEM bundles, e.g. eclipse-temurin:21-jre (Ubuntu 26.04) failed on emSign ECC Root CA - G3, while python:3.13-slim did not; alpine:3.22 ships a fixed bundle.
   • Fixed versions cited: certifi 2026.10.19, webpki-roots and webpki-root-certs 1.0.10, rustls-webpki 0.103.16 (0.102 and older get no fix), composer/ca-bundle 1.4.16, castore 1.0.22, pip 26.2.2.

   Remediation

   • Replace any server certificate chaining to emSign ECC Root CA - G3.
   • Run probes per CI runner type and behind each TLS inspection proxy; test real applications with mitmproxy on systems you own.
   • Scan and rebuild container images with the updated OS trust store; rebuild Go binaries built with affected versions; upgrade JDKs or add the blocked.certs entries and restart; upgrade and restart Node.js.
   • Check lockfiles (certifi, webpki-roots, rustls-webpki, composer/ca-bundle) with the provided vet policy; fix macOS laptops and Windows hosts verifying code signatures.
   • Search proxy and inspection logs for the intermediates, decide on credential rotation, and notify affected teams and vendors.
8. 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.
9. 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.
10. 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.
11. 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.
12. 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.
13. 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.
14. 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.
15. 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.