Cloudflare Sandbox Certificate Patch: Is Updating the SDK Enough?
The Sandbox SDK is updated and redeployed, but restoring an older snapshot brings back the old certificate trust. What else has to change to drop the eMudhra certificates?
- The relevant certificate policy lives in the image and its TLS clients, not simply in the SDK version.
- For 0.x, update the package and matching image; for 1.x, rebuild the image and replace old instances.
- Refresh recovery snapshots too: an old snapshot restores its original image.
A new npm package does not prove the image is patched
Check the environment that actually makes HTTPS connections. Cloudflare’s October 20 incident report concerns compromised keys for eight eMudhra intermediate certificates. Clients that trust them may accept forged server certificates.
Certificate verification can depend on an operating-system store, a runtime’s own list or a custom configuration. Updating an API package need not update any of those. The image and application dependencies therefore matter alongside the SDK.
Use the update path for your SDK generation
The Sandbox remediation notice directs 0.x users to update to 0.12.14 with a matching image and redeploy. Preserve any -python, -opencode or -musl variant. The base-image example is:
FROM docker.io/cloudflare/sandbox:0.12.14A custom image needs its own review. The Dockerfile reference permits copying only the Sandbox binary into another base image. Doing that does not refresh the base’s certificate store or runtimes.
The 0.12.14 release also updates Bun to 1.4.4. That closes the remaining trust gap for Bun and createBackup() uploads of archives at least 10 MiB in size; the preceding 0.12.13 image did not finish that work.
For 1.x, this incident does not require an SDK update, but the image still needs remediation. Refresh base images and the build cache before deployment. If configuration pins a digest, build and publish a patched image and update that reference.
Replace the instances and the recovery path
With named images under the durable_object scheduling policy, deployment updates the image map without restarting existing containers. A running instance retains its startup image until the application stops it and starts it again.
Plan that replacement around unfinished work and data you need to preserve. destroy() stops immediately and loses in-progress work and filesystem changes since startup. A successful deployment alone does not demonstrate that every instance is running the new image.
Snapshots capture filesystem state, not memory or running processes. They are tied to their original image and cannot be moved onto a different one. Restoring an old snapshot therefore brings back the old image, including its certificate trust.
After restoring the required data into an updated environment, create a new snapshot there. Otherwise, a later recovery can undo the image update.
Test each verifier your application uses
The remediation notice calls for testing the designated certificate-check hosts from inside the sandbox using each relevant TLS client. The expected result is certificate rejection.
A browser or curl result does not establish what a separate runtime will accept. A timeout or unrelated HTTP failure is also not evidence of certificate rejection. Inspect the reason for failure, and retain certificate verification when resolving errors.
Finish with two checks: which image is running now, and which image recovery will restore. Both need the corrected trust policy.