1-minute read
What a defender needs to know
Eight eMudhra intermediate certificates received weak P-384 private keys during an April 2025 key-generation ceremony, Cisco Talos reports. Six were TLS intermediates and two were for code signing. An attacker with an affected key could sign a fraudulent certificate; TLS impersonation also requires a way to intercept or redirect a connection to a client that accepts the chain. Talos said it had seen no malicious incidents involving these certificates as of October 21 at 14:00 UTC.
Chrome, Mozilla and Apple blocked the six TLS keys, Microsoft blocked the two code-signing keys, and eMudhra revoked the intermediates. Those changes leave a specific job for operators of VPN clients, gateways, proxies, build runners and software with separately managed trust stores: identify the validator in the deployed product and obtain its applicable update. For Go clients using crypto/x509, the Go CNA record names Certificate.Verify; security fixes shipped in go1.26.10 and go1.27.3. Rebuild and redeploy services with a fixed supported release, then confirm the running binary was replaced.
Talos lists eight certificate fingerprints in the full article and Snort SIDs 67363–67374. Use retained certificate chains and alert context to identify the affected intermediate. In an authorized test environment, verify that the updated client rejects a controlled chain containing it. Check vendor guidance separately for clients that use another validator or root bundle.