Fireblocks urges action after eMudhra intermediate certificate compromise
Fireblocks said eight eMudhra intermediate certificate authority certificates had compromised private keys and warned that some software outside normal browser controls may still trust them until updated. The company said it removed the affected certificates from relevant platform flows, found no use of them across its platform after its changes, and saw no impact to customer assets, communications or funds in its review.
Evidence and context
In its Oct. 21, 2026 blog post, Fireblocks said six of the compromised intermediates were TLS certificates and two were code-signing intermediates. It said browsers have blocked the certificates, but clients that do not check revocation data may continue to trust them. The post also said it is not publicly known whether attackers exploited the weakness against those clients. Fireblocks described the issue as a trust-store problem for software that still anchors trust to the affected intermediates, rather than a platform-wide failure.
The company said the immediate versions to install are Fireblocks Agent for Key Link 2.4.4 and, for users on the legacy Python SDK, version 2.19.1 or a move to the current Python SDK. Fireblocks said a new Co-Signer image dated 21.10.2026 no longer includes the affected certificates. For customers using callback authentication based on certificate pinning or a root-CA certificate, it said the affected certificates are not used, although routine upgrading is still recommended. For public key authentication, it advised upgrading to the latest Co-Signer image.
Fireblocks also said its platform hardening includes updating base images and software that use their own trust store, and that its secure enclaves validate certificates against a pre-reviewed list of certificate authorities on which eMudhra was not included. For customer-run software, it said users should update base images and host operating systems to releases with the revised trust store, refresh CA bundles used by language runtimes, and rebuild, redeploy and restart long-running services. It cited Python certifi 2026.10.19 or later and Go 1.27.3 or 1.26.10 as examples.
The post added that its review to date found no use of the affected certificates on the Fireblocks platform after the changes it made, and that third-party providers with their own trust configurations are being asked to confirm their upgrade status. Fireblocks said users should check their application’s actual TLS path, because a browser or curl test does not by itself prove a background service is protected. It said patched packages may also ship their own CA bundles and noted that the eight affected keys also appear in certificates cross-signed under Sectigo’s AAA Certificate Services root, so the full dependency chain should be checked.
Enrichment materials dated Oct. 20 and Oct. 21, 2026 indicate the wider response across the browser ecosystem was already under way, with Google and Mozilla issuing their own advisories and CERT-In publishing a separate advisory on Oct. 21. The background material also says Google received the report on Oct. 17, 2026 and Mozilla completed OneCRL distribution the same day, but those details come from the enrichment rather than Fireblocks’ post. Fireblocks said it will continue updating its blog as the work progresses; the timing of any further update was not specified.