> ## Content Index > Fetch the complete content index at: https://wealthlab.life/llms.txt > Use this file to discover other available public pages before exploring further. # Docker Sandboxes After the eMudhra CA Compromise - URL: https://wealthlab.life/docker-sandboxes-emudhra-ca-compromise-update/ - Published: 2026-10-23T00:09:07.000Z - Updated: 2026-10-23T00:09:07.000Z - Description: Docker rebuilt its built-in sandbox images after the eMudhra CA compromise. Existing sandboxes need recreation or trust-store updates. - Author: WealthLab - Tags: Security, Docker, AI Agents **Quick answer:** Docker rebuilt the template images for every built-in Docker Sandboxes kit after private keys for eight eMudhra intermediate certificate authorities were disclosed as compromised. Existing sandboxes do not inherit those rebuilt images, and updating the `sbx` CLI is not enough. Operators should either preserve needed work and recreate each sandbox with `--pull always`, or update the sandbox's CA package and any tools that carry a separate certificate bundle. This is source-based analysis, not a hands-on incident reproduction. WealthLab reviewed Docker's October 21 security notice, the October 20 public incident report and Mozilla's root-program incident record. We did not attempt to recover a CA key, connect to the public test hosts, or verify an image digest. The exact exposure of any workload depends on its image, trust store, bundled runtime certificates, network path and update state. ## What happened The public incident report says private keys for eight eMudhra intermediate CA certificates were compromised. Those intermediates chained to roots used by major browser and operating-system trust programs. A client that still accepts one of the affected chains could be made to trust an attacker-controlled certificate for a website or service. The report dates the disclosure to root-program teams to October 17 and its public incident page to October 20, 2026\. It says browser and operating-system vendors began distributing blocks between October 17 and October 20\. Mozilla's incident record describes the flawed intermediate-key generation and the coordinated response. Docker then published its Sandboxes-specific response on October 21. The evidence does **not** establish that every Docker Sandbox was attacked, or that a successful interception occurred in your environment. The practical issue is stale trust: non-browser clients and long-lived sandbox filesystems can continue using CA data that predates the block. ## Why the sandbox image matters A sandbox is isolated from the host, but software inside it still makes TLS connections for package downloads, source control, APIs and agent tools. Certificate validation happens inside that environment. If the sandbox's operating-system CA bundle or a language tool's private bundle still trusts an affected chain, a fully updated host browser does not automatically repair it. Docker says it rebuilt all built-in kit template images with updated CA certificates. Pulling a rebuilt image affects newly created sandboxes; it does not rewrite an existing sandbox filesystem. Likewise, replacing only the host-side `sbx` binary changes the CLI, not the CA files already stored inside a sandbox. ## Preferred path: recreate from a fresh image Recreation gives operators the clearest provenance boundary. Docker's documented pattern is: ``` sbx stop sbx rm sbx create --name --pull always codex ``` Replace `codex` with the kit or agent you actually use, and restore intentional options such as clone mode or additional kits. Before removal, preserve unpushed commits, generated files and any other state held only inside the sandbox. Docker warns that removing the sandbox deletes its filesystem. Use `--pull always` for new sandboxes during this response so a cached pre-rebuild image is not silently reused. Pinning by digest is useful for reproducibility, but a pin to an old digest also preserves the old trust store; change control must record the reviewed replacement digest when one is available to your workflow. ## Preservation path: update the existing sandbox If recreation would destroy required state, Docker gives this Ubuntu-template update path while the sandbox is running: ``` sbx exec -- sudo apt-get update sbx exec -- sudo apt-get install --only-upgrade -y ca-certificates ``` Restart applications in the sandbox afterward. This updates the operating-system package only. Python `certifi`, Java trust stores, Node.js, Go binaries, curl bundles and other tools may use their own CA material or embed it at build time. Inventory the actual TLS clients in the workflow and update them from their official channels rather than assuming one package covers all of them. ## Operator checklist 1. **Inventory sandboxes and kits.** Record which are disposable, which hold state and which can reach sensitive package registries, APIs or internal services. 2. **Preserve irreplaceable work.** Commit or export changes before removing a sandbox. Confirm the copy exists outside the sandbox. 3. **Choose recreation by default.** Stop and remove the old sandbox, then recreate with the same reviewed options and `--pull always`. 4. **Use in-place updates only when needed.** Upgrade the OS CA package, then separately check runtimes and applications with private trust stores. 5. **Restart long-lived clients.** A running process may retain certificates or TLS sessions even after files change. 6. **Verify behavior without weakening TLS.** Confirm package and API operations work with normal verification. Do not add `-k`, disable verification or globally trust a replacement certificate to silence errors. 7. **Record the boundary.** Capture the new image digest or package versions and the date checked. A recreated sandbox does not prove every nested tool bundle is current. 8. **Review outbound policy.** Restrict agent egress and credentials so a future trust failure has a smaller blast radius. ## Fit and non-fit cases **Recreate now:** disposable built-in-kit sandboxes, environments without unique local state, and security-sensitive agents that make authenticated outbound connections. **Update in place first:** a sandbox with irreplaceable or unpushed work. Preserve that work immediately, update the relevant trust stores, and schedule recreation once the state is safely externalized. **Not covered by Docker's notice alone:** arbitrary custom images, non-Docker sandbox products, host services, air-gapped systems, and applications with bundled CA stores. Use each distribution or runtime vendor's advisory and rebuild process. ## Rollback and failure handling Do not delete the only copy of sandbox state. Export or commit it before recreation, record the original kit and options, and retain the previous image reference long enough to diagnose functional regressions—but do not return a security-sensitive workload to an old trust store merely to avoid compatibility work. If a refreshed environment cannot connect, inspect the complete certificate chain, proxy interception and application-specific trust settings. Disabling verification is not a rollback. ## Related WealthLab guides - [Docker Engine and containerd security update](https://wealthlab.life/docker-engine-29-9-1-containerd-security/) — separate a runtime upgrade from image and workload remediation. - [Docker VPS production checklist](https://wealthlab.life/docker-vps-checklist/) — review patching, backup, network exposure and recovery together. - [Local AI-agent sandboxing checklist](https://wealthlab.life/github-copilot-local-sandboxing-operator-checklist/) — define credential, filesystem and network boundaries beyond certificate updates. ## Evidence boundary and sources Sources checked October 23, 2026: - [Docker security announcements, updated October 21, 2026](https://docs.docker.com/security/security-announcements/) — rebuilt built-in-kit images, the existing-sandbox limitation, recreation commands and Ubuntu CA-package update path. - [eMudhra Intermediate CA Compromise incident report, October 20, 2026](https://emudhra.we-have-a-problem.com/) — affected intermediate count, disclosure timeline, consequence, vendor response and the distinction between system and bundled trust stores. - [Mozilla Bugzilla incident record 2083449](https://bugzilla.mozilla.org/show%5Fbug.cgi?id=2083449) — root-program incident handling and technical investigation of the intermediate-key generation problem. No hands-on exploit, interception test, sandbox recreation or image-digest comparison was performed. Remediation versions and vendor status can change after publication; verify the current Docker notice and the update channel for every runtime in your own sandbox. *This analysis is non-commercial and contains no affiliate links.*