Another major security incident has swept the industry, and this time it's affecting pretty much everything.
The private keys for eight intermediate certificate authority (CA) certificates issued by eMudhra were compromised. Intermediate CAs sit between a trusted root and the certificates websites use. Anything an intermediate signs inherits the root’s trust. These eight chain to roots trusted by Mozilla, Google, Apple and Microsoft, which means they’re trusted by default on almost every browser, operating system and container base image in use today.
What happened
eMudhra generated the keys incorrectly, leaving them weak enough that almost anyone can recover them from the public certificates. With them, an attacker can issue a certificate for any domain (google.com, github.com, your API), and any software that trusts these CAs will accept it as genuine. The intermediates chain to eMudhra’s emSign roots and, through a cross-signature, to Sectigo’s AAA Certificate Services root. Both routes need to be closed.
Your browser is most likely patched, but your containers and VMs are most likely not
Firefox and Chrome blocked the compromised intermediates on 17 October, Apple on 19 October and Microsoft on 20 October, and eMudhra revoked them on 18–19 October. If you’re running an up-to-date browser, you’re covered.
Outside the browser, software trusts whatever is in its local CA bundle. On hosts and VMs, that bundle comes from the OS, so updating the ca-certificates package fixes it. Containers are trickier: the bundle is baked into each image at build time, so any image built before its base picked up the patch still trusts the compromised keys, no matter how up to date the host is. Those images need to be rebuilt and redeployed, and the same goes for CI runners and build images.
How Cycle is protecting you
For customers on Cycle, the platform layer isn’t affected. Host servers, private networks and load balancers communicate with Cycle services using Cycle’s own private certificate authority, not the public trust store. No server restarts are required.
Your workloads are a different matter. Cycle doesn’t modify the trust store inside your container images or VMs, so those may still be vulnerable and need the steps below.
Things you should do immediately
- VMs: update the OS ca-certificates package (patched versions exist for Debian, Ubuntu, Alpine, Fedora and Arch), then restart long-running services.
- Containers: Each image carries its own trust store. Rebuild on an updated base image and redeploy. (On Cycle, rebuild and redeploy your stacks, or reimage your container with a new image.)
- Language runtimes: some ignore the OS list. Update Python certifi (2026.10.19+), Go (1.27.3 / 1.26.10) and Rust webpki-roots (1.0.10), and rebuild anything that compiles its trust list in. Unfortunately, the Node.js fix is still pending as of now, so keep your eyes peeled for patched LTS versions.
Verify if you're affected
Mozilla’s Dennis Jackson runs a test site and patch tracker at https://emudhra.we-have-a-problem.com/. It checks your browser automatically. For containers, VMs and hosts, run both of these from inside each:
curl https://dv-g3b-emudhra.we-have-a-problem.com/curl https://dv-g3b-aaa-emudhra.we-have-a-problem.com/A certificate error (for example, unable to get local issuer certificate) is what you want to see. If either returns Your client successfully connected to the site. That’s bad!, that workload still trusts the compromised keys and needs patching.
Questions?
If you’re running on Cycle and aren’t sure whether a workload is affected, or need help rebuilding and redeploying, reach out to the Cycle team on Slack or post in the Cycle community. Not a Cycle user? Our community Slack is public, and you're welcome to join and collaborate with other DevOps and Infrastructure professionals. We'd love to have you!