Eight eMudhra intermediate CA certificates have compromised private keys. Six are TLS intermediates. Anyone can use them to forge HTTPS certificates that impersonate any website to clients that still trust them. The other two are code-signing intermediates. Browsers have blocked the certificates. But many clients outside the browser ecosystem never check revocation data, so they will keep trusting these until someone updates them. It is not publicly known whether attackers exploited the weakness against those clients.
Who Needs to Act
If you run the Fireblocks Agent for Key Link, upgrade to 2.4.4 now. If you are still on the legacy Python SDK upgrade to 2.19.1, or move to the current Python SDK. Everyone else should still work through the sections below, but these two are the immediate ones.
How We Are Responding
Platform
We are in the process of hardening the Fireblocks platform by updating our base images and all of the software and applications that use their own trust store. We also removed the affected eMudhra certificates from the relevant flows, and are reviewing our corporate environment to ensure we remove any potential use of the affected certificates. Our secure enclaves also validate certificates against a pre-reviewed list of certificate authorities. eMudhra was not on that list.
What We Found
We reviewed the Fireblocks platform for use of the affected certificates and found none. Our investigation to date has found no impact to customer assets, communications or funds from the eMudhra certificate incident.
Third-Party Providers
We work with third-party providers that maintain their own trust configuration. We have reached out to them and are actively engaging them to confirm their upgrade status. This work is ongoing.
Software You Run
Software you run carries its own trust settings, so the platform changes above do not reach it. We released upgraded packages for that software. The breakdown by component, with the version to install, is below.
What You Need to Do
Co-Signer callback handler. Whether you need to act depends on how you authenticate the callback. Fireblocks supports multiple callback authentication modes, and each anchors trust differently.
| Callback Authentication Mode | What Anchors Trust | What to Check |
|---|---|---|
| Certificate pinning | The certificate you provided to the Co-Signer | Confirm the pinned certificate is the one you provisioned. |
| Root-CA certificate | The Root-CA you provided to the Co-Signer | Confirm that root is your own and is not an affected emSign or AAA Certificate Services root. |
| Public key authentication | A public CA signs your callback server’s TLS certificate, and messages are JWT-signed | Upgrade to the latest Co-Signer image 21.10.2026 |
A new Co-Signer image, 21.10.2026, no longer includes the affected certificates. For pinning and Root-CA modes, the certificates are not used, and upgrading is recommended as routine maintenance.
Upgrade the Following Customer-Run Software:
- Fireblocks Agent for Key Link: upgrade to version 2.4.4.
- Legacy Python SDK: upgrade to 2.19.1, or move to the current Python SDK and update your base image or host as described below.
- Recovery Kit: we will update the blog when a new version of the recovery kit is ready.
Everything Else
For everything else, including code you deploy that uses the operating system trust store, upgrade your base images and host operating systems to a release with the revised trust store. Update the CA bundle your language runtime uses as well. For example, Python certifi 2026.10.19 or later, and Go 1.27.3 or 1.26.10. Rebuild, redeploy, and restart long-running services. Check the patched package tracker for your runtime.
Our team will be continuing to make progress, and will update this blog post soon with all additional details.
FAQs
-
Do I need to act if I only use the Fireblocks Console and Mobile apps?
Update your browser and your operating system to the latest versions. Our Mobile apps pin certificates, so a forged certificate that chains to the affected intermediates is not accepted. -
Do I need to upgrade my Co-Signer?
It depends on your callback authentication mode. See the table above. -
Did the compromise put my assets at risk?
A forged certificate lets an attacker impersonate a server to a client that still trusts the affected intermediates, so the exposure sits in software that trusts them. We removed those certificates from the relevant flows on the Fireblocks platform, and our review found no usage of them across the platform after the changes we made. For customer-run software, the updates prevent future acceptance of the affected certificate chains, once you verify the application’s actual TLS path. It is not publicly known whether attackers exploited the weakness against clients outside browsers. -
How do I check that I’m patched?
Confirm the component runs the version listed above, then test through your application’s actual TLS path. A passing browser or curl test does not prove a background service is protected. Dennis Jackson of Mozilla maintains a test site with non-browser instructions and a list of patched packages: https://emudhra.we-have-a-problem.com/ -
Is upgrading the SDK enough?
Not always. Certificate verification often happens in an HTTP library, a language runtime, or the operating system. Patched packages also ship their own CA bundles, such as Python certifi. The eight affected keys also appear in certificates cross-signed under Sectigo’s AAA Certificate Services root, so confirm your update covers both chains. Check the full dependency chain. -
I see certificate errors after patching. What should I do?
Do not disable verification, because that removes the protection the update restores. Contact Fireblocks Support. -
Where will updates appear?
On this page. We will update this post as this work progresses.
References
- Google, Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates
- Dennis Jackson, eMudhra Intermediate CA Compromise
- Python Software Foundation, Information for Python users regarding the eMudhra / emSign CA certificate security incident
Last Updated: October 2026.
