TL;DR

The private keys of eight eMudhra intermediate certificate authority (CA) certificates have been compromised. The intermediates chain to roots trusted by the Mozilla, Microsoft, Apple and Chrome root programs, and separately cross-sign to the “AAA Certificate Services” (Sectigo/Comodo) root. Major browsers and operating systems already block the compromised chains. Some non-browser TLS clients, including server operating system trust stores, do not receive this protection automatically and require a software update.

The risk: an attacker able to intercept or redirect an outbound TLS connection may impersonate the destination service if the client still trusts the compromised certificate chains.

Scalingo released updated stack images, including the ca-certificates fix, to production on October 21, 2026 at 16:21 CEST (14:21 UTC). We found no evidence of exploitation against Scalingo infrastructure or of any interception of customer traffic.

Action required: rebuild and redeploy applications that establish outbound TLS connections to external systems. Redeploying is sufficient to pick up the fix; a restart alone is not.

What Happened?

On October 17, 2026 at 20:06 UTC, Mozilla received a report that the private keys of eight eMudhra intermediate CA certificates had been compromised (Mozilla Security Blog). The keys were incorrectly generated during an April 2025 key ceremony, making them trivially recoverable from the public certificates (eMudhra disclosure). The intermediates chain to “emSign Root TLS CA - G3”, trusted by the Mozilla, Microsoft, Apple and Chrome root programs, and are separately cross-signed by “AAA Certificate Services” (Sectigo/Comodo).

Firefox and Chrome blocked the compromised certificates the same day, Apple devices followed on October 19 and Microsoft platforms on October 20. No certificate transparency log entries exist for the compromised intermediates, so CT-enforcing browsers could not have been targeted through publicly logged certificates; other TLS clients, including server operating system trust stores, remain exposed until their trust store is updated.

eMudhra revoked the eight intermediates and states that seven were never deployed in production and the eighth never issued end-entity certificates. Ubuntu published USN-8944-1 on October 20, 2026, with fixed ca-certificates versions; other distributions and language ecosystems also published fixes, see the eMudhra disclosure site for an actively maintained list.

Risk and Exploitation Conditions

An attacker who can intercept or redirect an outbound TLS connection may impersonate the destination service if the application still trusts the compromised certificate chains.

This requires an interception or redirection capability; possessing the compromised keys alone does not grant access to a target’s containers, environment variables, or databases. The destination’s legitimate certificate may come from an unrelated CA — this does not rule out the attack, since the attacker presents a different, fraudulent certificate instead. Consequences depend on the connection, and can include exposure of credentials, tokens and data, and tampering with responses consumed by the application; confidentiality and integrity are affected, not availability.

What We Did

Scalingo released updated stack images, including the ca-certificates fix, to production on October 21, 2026 at 16:21 CEST (14:21 UTC). Rebuilding and redeploying an application on an affected stack is sufficient to pick up the fix.

Remediation of our internal server fleet followed the same day: updating the trusted certificate bundle used by our configuration management tooling and restarting the long-running services that read this bundle only at startup.

What You Should Do

1. Check your application’s stack and its lifecycle status. The fix is available for scalingo-26, scalingo-24 and the deprecated scalingo-22.
2. Rebuild and redeploy each affected application; see the Git deployment instructions or manual GitHub deployment. A restart alone does not update the operating system trust store inside your application’s containers.
3. After redeploying, check the installed ca-certificates package version in a one-off container, for example scalingo --app my-app run dpkg -l ca-certificates, and compare it against the fixed versions below.
4. If your application or its dependencies embed their own certificate trust store independently of the operating system (common for some language runtimes and package managers), check and update it separately. See the eMudhra disclosure site for a list of affected software and available fixes.
5. Prioritize applications that establish outbound TLS connections to external systems, such as APIs, webhooks, SMTP servers or remote databases. These are the connections an attacker would need to intercept to exploit this issue.
6. You can test whether a given TLS client still trusts the compromised chains using the public test endpoints described on the eMudhra disclosure site.

Fixed ca-certificates package versions published by Ubuntu (USN-8944-1):

Product Impacts

Scalingo PaaS

Updated stack images, including the fix, are now available in production for scalingo-26, scalingo-24 and the deprecated scalingo-22. Applications built before the fix was deployed remain at risk, if they make outbound TLS connections to external systems, until they are rebuilt and redeployed.

Contact

If you have questions about this bulletin, contact Scalingo support at support@scalingo.com or through the in-dashboard chat.

Timeline

Changelog

• 2026-10-21: Initial publication of SSB-2026-006.