Docker Updates Sandbox Trust Stores After eMudhra CA Compromise
Tech GuruQuick Answer
Docker rebuilt built-in Sandbox template images after eMudhra intermediate CA private keys were disclosed. Inventory existing sandboxes and cached images, preserve needed files, recreate with --pull always or update CA certificates in place, restart applications, and verify trust-store state.
Confirm Scope And Apply The Supported Remediation
What to do now: Inventory sandboxes, image sources, caches, custom templates, and trust stores; preserve required files; refresh or rebuild affected images or update CA certificates; restart applications; test TLS behavior; and retain before-and-after evidence.
Last verified: 2026-10-21 UTC. Recheck the authoritative advisory and supported distribution channel before changing production.
Scope And Authority
| Product scope | Docker Sandboxes created from Docker built-in kit template images |
|---|---|
| Advisory | Docker Sandboxes response to eMudhra CA compromise |
| CVEs | |
| Authoritative release date | 2026-10-21 12:52:37 UTC |
| Authority revision date | 2026-10-21 12:52:37 UTC |
| Affected versions | Existing Docker Sandboxes and cached built-in kit images that retain the compromised eMudhra intermediate CA trust path; applicability depends on the trust store actually present in each sandbox or custom template. |
| Fixed version | Recreate each affected sandbox with --pull always to fetch rebuilt images, or update the ca-certificates package in place and restart applications; rebuild custom templates from updated base content. |
| CVSS base score | Not provided by the authority |
| CVSS severity | Not provided by the authority |
| Exploitation status | Docker does not state that Docker Sandboxes were maliciously exploited; the compromised CA private keys were publicly disclosed.; no exploitation claim is inferred. |
What Changed
Docker rebuilt sandbox template images for all built-in kits after private keys for eight eMudhra intermediate certificate authorities were publicly disclosed. Existing sandboxes and cached images are not changed by updating the sbx CLI alone.
What To Validate Now
- Inventory. Identify Docker Sandboxes, built-in and custom kit images, image pull history, cached templates, trust-store versions, workloads, owners, and files that must be preserved before recreation.
- Establish applicability. Inspect the trust store in each sandbox or template. Do not infer that an existing sandbox is protected from an updated sbx CLI or a newly pulled image because neither changes the running sandbox filesystem.
- Remediate. Preserve needed files, stop and recreate affected sandboxes with --pull always, or update ca-certificates in place and restart applications. Rebuild custom templates from updated distribution content.
- Validate. Confirm the rebuilt image or trust-store package, verify the compromised chain is no longer trusted, restart applications, test outbound TLS, and retain image, package, and recreation evidence.
- Retain evidence. Preserve asset and owner identifiers, the applicability decision, before-and-after versions, change approval, installation output, validation results, and any exception or rollback record.
Operational Cautions
Removing a sandbox deletes its filesystem, so preserve required files and unpushed work first. Updating sbx alone does not change existing sandboxes, and software with a bundled trust store may need a separate update.
Evidence To Retain
- Exact product, release stream, package or application version, enabled feature, environment, and accountable owner.
- UTC timestamps, authority revision, approved change record, installer or package-manager output, and resulting version.
- Relevant logs and monitoring evidence, test results, exceptions, compensating controls, and rollback decisions.
Related TechGeeks Resources
Authoritative References
Correction policy: If the authority changes affected versions, fixed versions, severity, exploitation information, mitigations, or required action, TechGeeks will update this notice and its verification date.
