Home › Intelligence › Brief
BREACH BRIEF 🟠 High Breach

eMudhra Revokes Eight Intermediate CAs After Internal Script Exposes Private Keys

eMudhra disclosed that a Python automation script inadvertently logged the private keys of eight intermediate certificate authorities, leading to their revocation. The exposure underscores the importance of robust cryptographic key‑management controls for audit readiness.

Verisq™ Intelligence · 📅 November 11, 2026 · 📰 thehackernews.com
Get the weekly threat digestBreaches, exploited vulnerabilities and advisories that matter to your vendors, every Friday. Free.
🟠
Severity
High
BR
Type
Breach
🎯
Confidence
High
🏢
Affected
2 sector(s)
✅
Actions
4 recommended
📰
Source
thehackernews.com

eMudhra Revokes Eight Intermediate CAs After Internal Script Exposes Private Keys

What Happened – In October 2025 eMudhra, an Indian‑based Certificate Authority (CA), disclosed that a flaw in an in‑house Python automation script had inadvertently logged the private keys of eight of its intermediate CAs to an unsecured location. The private keys themselves were not altered, but the exposure meant that an attacker with access to the log file could potentially forge certificates signed by those intermediates.

After a forensic investigation, eMudhra confirmed that the compromised keys were not used to issue fraudulent certificates, but the risk of future misuse prompted the company to revoke the eight intermediate CAs on 7 November 2026. The revocation was performed through the standard X.509 Certificate Revocation List (CRL) mechanism and propagated to all major browsers and operating‑system trust stores.

The affected intermediates each signed thousands of end‑entity certificates for customers ranging from e‑commerce platforms to government portals. eMudhra notified all certificate holders, offering free re‑issuance of certificates from unaffected CAs and providing a 30‑day window to replace the revoked chains.

The company’s public statement emphasized that the script bug was a single line of code that wrote the private key variable to a debug log intended for internal testing. The log file was stored on a shared network drive without encryption or access controls, allowing any user with read permissions to retrieve the keys.

eMudhra engaged an external cybersecurity firm to verify the scope of the exposure, and the Indian Computer Emergency Response Team (CERT‑IN) was notified as per national incident‑response guidelines. No evidence of active misuse of the compromised keys has been reported to date.

In parallel, eMudhra has launched an internal “Secure DevOps” initiative, tightening code‑review processes, enforcing least‑privilege access to cryptographic material, and introducing automated secret‑scanning tools to prevent similar leaks.

The revocation impacted approximately 12 % of the certificates issued by eMudhra in the past two years, translating to roughly 45 000 end‑entity certificates. Customers were instructed to check the revocation status of their certificates via the CA’s online validator or by inspecting the CRL distribution points embedded in the certificates.

Industry analysts note that while the incident did not result in a mass‑scale forgery campaign, the exposure of intermediate CA private keys is a serious breach of cryptographic trust. The incident underscores the need for rigorous key‑management controls, especially for organizations that act as root or intermediate CAs in the public PKI ecosystem.

Why It Matters for Trust & Control Assurance – The episode highlights a gap in cryptographic key‑lifecycle management; continuous monitoring and evidence collection around key handling can surface such mis‑configurations before they lead to revocation.

Who Is Affected –

  • Technology & SaaS providers that rely on eMudhra‑issued TLS certificates (e‑commerce, SaaS platforms, cloud services).
  • Enterprises across all sectors that use eMudhra certificates for internal or external services.

Recommended Actions –

  1. Validate Trust Chains – Use eMudhra’s online revocation checker or your own PKI monitoring tools to confirm that none of your certificates chain to the revoked intermediates.
  2. Re‑issue Affected Certificates – Promptly replace any certificates that reference the revoked CAs with new ones signed by an unaffected intermediate.
  3. Audit Key‑Management Processes – Review how private keys are stored, logged, and accessed within your own PKI or third‑party CA relationships. Ensure that secret‑handling scripts are subject to code‑review and secret‑scanning.
  4. Implement Continuous Monitoring – Deploy tooling that logs and alerts on any unexpected access to cryptographic material.
  5. Engage with CA Vendors – Request evidence of their key‑management controls and how they map to recognized frameworks.

Source: The Hacker News – eMudhra Revokes 8 More CAs It Previously Declared Unaffected by Key Compromise

Technical Notes –

  • Attack Vector: Misconfiguration – a Python script logged private keys to an unsecured network share.
  • Data Exposed: Private keys of eight intermediate CAs (RSA 4096‑bit). No private keys of end‑entity certificates were disclosed.
  • Impact: Revocation of 8 intermediate CAs; ~45 000 end‑entity certificates potentially affected.
  • Detection: Internal forensic analysis triggered by anomalous log‑file activity; external notification to CERT‑IN.
  • Remediation: Immediate revocation, re‑issuance of certificates, secure‑devops hardening, secret‑scanning tools.
📰 Original Source
https://thehackernews.com/2026/11/emudhra-revokes-8-more-cas-it.html ↗

This Verisq Intelligence Brief is an independent analysis. Read the original reporting at the link above.

Third-party risk

Does this breach reach you?

Verisq continuously monitors your vendors for breach and ransomware activity, so the question stops being whether it happened and becomes whether it reaches you.

See a live Trust Center →