Docker disclosed CVE-2026-105445 involving personal access token reassignment during account-to-organization conversion. It says the production fix was deployed on September 30, the day of the report, and potentially affected parties were notified separately. Docker official announcement
The issue allowed a reassigned token to carry the target user’s registry access scope. Docker distinguishes this from changing account passwords or two-factor settings through the web interface. Presenting the fixed incident as a current takeover of all accounts would misstate its scope.
On this page
Registry publishing permission is part of the supply chain
A container registry stores images that deployment systems later execute. If automation pulls an image under a trusted name, permission to publish under that name becomes part of the software supply path. Registry-level push or deletion can matter even without access to account-password settings. Read this advisory with that distinction between registry authority and full web-account takeover intact.
A PAT is a secret used by automation to act for an identity. If the secret stays unchanged while its owner or associated authority changes, someone holding the same value can acquire an unexpected scope of access. Review the token’s owner, permitted operations, and consuming pipelines alongside its description and creation date rather than treating the secret as an isolated configuration value.
Tags and digests provide different evidence
A tag is a name pointing to an image and can be moved to different content. A digest identifies particular image content. During an investigation, the tag alone may be insufficient to establish what a past deployment actually ran. Preserve the digest used by the deployment and connect it to registry publishing records and the relevant build history.
A currently healthy image does not explain every earlier deployment. Separate images published during the period under review, pipelines that consumed them, and the time they were replaced. This helps establish the scope of image changes; it is not evidence that an image was malicious merely because a deployment referenced a particular tag or ran during the exposure window.
Correlate the vendor notice with internal automation
An organization receiving an exposure notice should identify the listed tokens and accounts, then compare publishing and deletion with expected pipeline activity. Credential replacement should include verifying old-token deactivation and reviewing the new token’s authority. Identify the account owning each automation so that a personnel or ownership change does not leave its operational dependencies unclear.
Docker states that it notified exposed users and that those without the specified notice were not exposed through this conversion flow. General registry hygiene remains useful, but do not present routine findings as proof of exposure to this incident. Separating organization-owned automation from personal tokens also makes future ownership reviews more manageable.
Evidence for a notified organization
- Confirm the notification and the affected account or organization.
- Reconcile token scope and image publication or deletion with expected work.
- Record the image digests used by running deployments.
Separate routine token hygiene from incident-specific impact assessment. Base the latter on vendor notifications and your own records.
Announcement reference date: 2026-10-12 · Checked: October 24, 2026
.jpg){kind=link}