← Blog · Guides

eMudhra certificate compromise: what to check in your container image

October 20, 2026

On 20 October 2026 Cloudflare published an incident write-up that every team shipping containers should read. Its opening: "On October 19, 2026, at approximately 17:00 UTC, Cloudflare became aware that private keys associated with eight eMudhra intermediate certificates were compromised. These certificates were widely trusted by browsers, operating systems, and also within Cloudflare." And why it matters: "Because the keys themselves are weak, an attacker can create a forged certificate for any domain and use it to impersonate servers to intercept or modify traffic."

Two limits are worth keeping in view, both in Cloudflare's own words. On exploitation: "Our security review has not identified active exploitation of this issue on Cloudflare services." On scope: "This work addresses certificate-based authentication, not a weakness in TLS's encryption algorithms." This is eight intermediate certificates from one certificate authority, not a break in TLS itself.

Why a container is where this gets missed

Browsers were the easy part. Cloudflare notes that browser makers fixed it "with a flip of a switch", using quick-revocation mechanisms such as Chrome's CRLSets. Your application is a different story. When your code calls a payment API, a webhook endpoint or another service over HTTPS, something decides whether that server's certificate is trustworthy, and that something is usually not a browser.

Cloudflare's guidance to its own container customers is direct: "Customers using Cloudflare Containers, including Sandboxes, should review their container images and application dependencies for affected certificate trust stores and apply updates based on your deployed image." The phrase that matters is your deployed image. A trust store is a file. If it was copied into your image at build time, your running app keeps using that exact file until you rebuild the image and redeploy it. Updating packages on your laptop changes nothing in production.

Look beneath the SDK

The most useful section of the write-up is its developer guidance: "An API client may delegate certificate verification to an HTTP library, a language runtime, the operating system, or a custom trust configuration. Updating the SDK alone may not change the underlying policy."

In practice an application can trust certificates through several different paths, and they do not all update together:

  • The operating system's bundle. On Debian, Ubuntu and Alpine based images this is the ca-certificates package. It only changes when the image is rebuilt with an updated package.
  • The language runtime's own bundle. Node.js ships a built-in certificate list compiled into the binary, so a Node app may ignore the OS bundle entirely unless configured otherwise. Upgrading the Node version is what changes it.
  • A package that carries its own list. Python's requests, for example, uses the certifi package by default. Java uses its own cacerts keystore inside the JDK.
  • A custom trust configuration. A pinned CA file in your repo, a setting in an HTTP client, or a bundle someone vendored years ago.

Mozilla's Dennis Jackson has crowdsourced a list of commonly used packages that have been patched, along with a test site. Cloudflare adds a warning about that list: some of these packages "may be indirect dependencies of your software stack, so look at the dependency tree."

What to do with your image

  1. Find out which trust path your app uses. Check the base image, the language runtime version, and any HTTP or TLS library in your dependency tree, including indirect ones.
  2. Update at each layer that applies. Pull a refreshed base image or update ca-certificates in your Dockerfile, upgrade the runtime if it bundles its own list, and bump packages like certifi against the patched list.
  3. Rebuild and redeploy. Cloudflare's wording: "Apply the relevant dependency updates, rebuild affected images, and confirm whether applications require a reload, restart, or redeployment." A rebuilt image that is not running yet has fixed nothing.
  4. Verify on the path your app actually uses. This is where good intentions go wrong: "A successful browser test does not prove that a background service is protected. Neither does a curl test if the application uses a different verifier." Run the check from inside the running container, using the same language and library your code uses.

A quick way to see what an image contains, run on your own machine against the image you deploy:

# Debian / Ubuntu based image: which ca-certificates version is baked in?
docker run --rm your-image:tag sh -c 'dpkg -s ca-certificates | grep Version'

# Alpine based image
docker run --rm your-image:tag sh -c 'apk info -v ca-certificates'

# Python app using requests / certifi
docker run --rm your-image:tag python -c 'import certifi; print(certifi.__version__)'

# Node app: the bundled list changes with the Node version
docker run --rm your-image:tag node -v

Compare what you find against the patched-package list, then rebuild.

Do not make the errors go away the wrong way

After you patch, some outbound calls may start failing with certificate errors. That is the patch working: a certificate chain your app used to accept is no longer trusted. Cloudflare is blunt about the wrong response: "Once you patch, you may notice certificate errors in your dashboards. It's important to not resolve these errors by disabling verification. That would remove the authentication protection these updates are intended to restore."

So no verify=False, no NODE_TLS_REJECT_UNAUTHORIZED=0, no InsecureSkipVerify as a quick fix. If a service you call fails after patching, the fix is for that service to get a certificate from a chain that is still trusted. Tell them, and keep verification on while you wait.

What comes next

Cloudflare's closing point is that a trust store should not be a static list baked in once and forgotten. It names the upki project as an example of trust stores that can be updated quickly with revocation information. Until that is normal, the practical habit is simple: treat certificate trust like any other dependency. Rebuild images on a schedule, not only when you change your code.

This is a different problem from the Let's Encrypt change we covered this week. That one is about how a certificate authority checks your domain before issuing a certificate; see Let's Encrypt will validate your domain from seven places. This one is about which certificates your app trusts when it connects out. Different mechanism, different fix.

Source: Cloudflare, "eMudhra certificate compromise", published 20 October 2026, read 21 October 2026.