eMudhra/emSign: Weak Intermediate CA Private Keys (CVE-2026-111943)

Eight eMudhra/emSign intermediate CA certificates created in April 2025 utilized P-384 ECC keys with trivially small private scalars (d in {4, 56, 66, 115, 155, 156, 230, 237}). Because these scalars are so small, the private key can be recovered from the public certificate in milliseconds. Six of the compromised intermediates could mint TLS certificates for any hostname, while two functioned as code-signing CAs. While major browsers (Chrome, Firefox, Safari) and OS vendors (Microsoft, Apple) have pushed blocks, non-browser software and environments relying on bundled or outdated CA trust stores remain vulnerable.

Attack Chain

1. Recovery: Attacker extracts the public key from an affected intermediate certificate and performs a brute-force search across the 8 known scalar candidates to derive the private key.
2. Forgery: Attacker generates a new leaf key pair and signs a certificate for any target hostname (CN/SAN) using the recovered CA private key.
3. MITM Setup: Attacker deploys a TLS server configured with the forged certificate chain.
4. Redirection: Attacker forces victim traffic to the MITM server (e.g., via DNS poisoning or ARP spoofing).
5. Interception: Victim client connects; because the trust store is unpatched, it validates the forged certificate, allowing the attacker to decrypt and inspect all TLS traffic.
6. Post-exploitation: Attacker injects malicious payloads, steals credentials, or establishes persistent C2 channels via the compromised connection.

Impact

Successful exploitation allows for the interception of HTTPS traffic (MITM), deployment of trusted phishing sites for any domain, and the creation of valid-looking code-signing certificates to sign malware. All traffic protected by software using unpatched CA bundles or trust stores is subject to decryption.

Recommendation

• Update CA trust stores and cryptographic libraries immediately: Python certifi (2026.10.19+), pip (26.2.2+), Go (1.27.3/1.26.10+), and Node.js (22.23.4/24.22.1/26.12.1+).
• Add the 16 SHA-256 hashes of the compromised CA certificates to the blocked.certs list for all Java environments.
• Rebuild containers and binaries that bundle trust stores (e.g., Debian/Ubuntu/Alpine/RHEL-based images).
• Scan internal PKI and trust stores for the specific root certificate fingerprints listed in section 7 of the source.