Sandbox SDK 0.12.14 removes compromised eMudhra CAs – immediate update required

Cloudflare’s Sandbox SDK images before version 0.12.14 included trust for eight eMudhra intermediate CAs whose private keys were disclosed. Any HTTPS request that leaves a sandbox container directly – for example calls from mountBucket(), backups, gitCheckout(), or custom code – could be intercepted with a forged certificate that chains to those compromised authorities. The update to 0.12.14 revokes that trust, forcing containers to validate certificates against a clean root store.

What changed

Version 0.12.14 of the Sandbox SDK replaces the bundled CA bundle so that the eight eMudhra intermediates are no longer trusted. The change is limited to the SDK image; the SDK’s API and runtime behavior remain the same. The rollout mechanism automatically replaces running sandboxes with containers based on the new image when the deployment is updated.

Why it matters to engineers

• Security risk: With the compromised CAs trusted, an attacker who can present a forged certificate for any hostname can silently decrypt or modify outbound HTTPS traffic from the sandbox.
• Operational impact: Services that rely on direct outbound HTTPS – such as data ingestion, external API calls, or code checkout – are exposed until the image is updated.
• Scope of exposure: The vulnerability only affects HTTPS on port 443 that terminates inside the sandbox. TLS on other ports (e.g., Cloudflare tunnels) is not covered by the fix.

How to remediate

All practitioners should upgrade to the patched image immediately. The steps are:

1. Update the SDK dependency in package.json to @cloudflare/sandbox@0.12.14 (or a later version).
2. Modify the FROM line in the sandbox Dockerfile to reference the matching image tag, preserving any suffix such as -python, -opencode, or -musl.

   FROM docker.io/cloudflare/sandbox:0.12.14

3. Redeploy the service. The platform’s rollout process will replace existing containers with the new image.
4. If you are on the next prerelease channel, upgrade to 0.13.0-next.825.1 or later.

For environments that cannot be updated immediately and are running SDK 0.8.7 or newer, route all outbound HTTPS through a Worker that performs certificate validation. Enable interception in the sandbox class and forward requests via fetch:

import { Sandbox, ContainerProxy } from "@cloudflare/sandbox";
export { ContainerProxy };
export class MySandbox extends Sandbox {
  interceptHttps = true;
}
MySandbox.outbound = (request: Request) => fetch(request);

After deploying this Worker, stop any running sandboxes so they restart with the injected interception certificate. Note that this approach does not protect TLS on non‑HTTPS ports, and clients that ignore the injected certificate will fail to connect.

Operational considerations

• Verify that your CI/CD pipeline pulls the updated image tag; cached layers may otherwise keep the old CA bundle.
• Test any custom outbound logic (e.g., custom TLS libraries) after the upgrade, as the new trust store may reject previously accepted certificates.
• Monitor sandbox rollout status to ensure all instances have been replaced before assuming the risk is mitigated.
• Document the fallback Worker approach as a temporary mitigation, not a long‑term solution.

Related CloudNinjas coverage: hands-on guides.

What This Means For Practitioners

Immediately upgrade to Sandbox SDK 0.12.14 (or a newer release) and redeploy your containers. If you cannot upgrade, enable HTTPS interception via a Worker as a stop‑gap, but plan to replace the image promptly. Keep an eye on future SDK releases for additional hardening of the CA bundle and for any guidance on protecting non‑HTTPS outbound traffic.