Docker Hub fixes token ownership changes during account conversion

Docker's October 12 security advisory describes a flaw in Docker Hub account conversion. A personal access token created by one account could become attached to another user's identity without changing the secret. The holder of that secret could then authenticate to the registry with the new owner's permissions, within the token's scope. Docker tracks the issue as CVE-2026-105445.

The mechanism concerns an identity transition that preserved a usable credential. I find it more instructive than a generic warning about keeping tokens secret. An attacker could create and retain the token legitimately before the vulnerable conversion changed what it authorized. Secret storage alone would not prevent the service from making that change.

I value Docker's repeatable build files and content-addressed artifacts because they make software distribution easier to account for. Registry authorization is another necessary part of that account. A build process can be understood in detail while a credential transition still grants someone the ability to publish under a trusted repository name.

Conversion preserves a namespace for a practical reason

Docker's advisory explains why account conversion exists. Hub does not provide a way to move a repository between accounts. Converting an individual account into an organization preserves references such as alice/app, while transferring administration to an existing account chosen as the new owner.

The conversion documentation describes the resulting distinction. The Docker ID remains the repository namespace, but it becomes an organization. Its owner signs in with a separate individual account to manage that organization. Preserving a repository reference and assigning an administrator are separate operations in the resulting account model.

That arrangement creates a migration problem for existing automation. A process may already authenticate using a PAT from the individual account being converted. I can understand why a product would try to preserve that workflow. However, continuity of repository access does not justify silently changing the principal represented by an existing secret.

The vulnerable behavior began on August 26, 2024, according to Docker. Conversion reassigned the account's PAT ownership records to the newly named owner. It neither rotated nor revoked the token secret. The chosen owner also received no confirmation request or notification. Those conditions allowed someone initiating a conversion to create an active credential for another identity.

The token remained known to its creator

The attack described by Docker starts with an attacker-controlled account and a PAT generated on that account. The attacker converts the account into an organization and names a target user as its owner. Conversion changes the PAT's ownership record to the target. The attacker retains the original secret, which now authenticates as that user at the registry.

No theft of the target's token is required in that sequence. The error is in how the server changes the association between a secret and an identity. The failed invariant is that an existing credential must not gain a different principal's authority merely because someone else initiates an account migration.

The distinction between principal and namespace is particularly important here. The migration intends to preserve an image reference under the converted namespace. A reassigned token can act with the target user's registry permissions, which may extend beyond that namespace. Docker says a transferred token could potentially pull, push, or delete images in repositories the target could access, subject to the token's scope.

That scope condition should remain in an explanation of impact. It does not establish that every transferred PAT had every possible registry permission. At the same time, publishing into a repository under a legitimate name is sufficient to create a supply-chain concern. Docker rated the issue critical on that basis.

Registry authority did not include web account takeover

Docker explicitly limits the affected capabilities to registry access. The vulnerability did not grant access to the Hub web interface or permit changes to the target's password, email address, or two-factor settings. An incident assessment needs that distinction because account administration and image distribution expose different operations.

The absence of web access does not make a registry credential harmless. For an application that relies on images published by an organization, write access can affect what that organization distributes. A risk review should therefore examine the operations the token could perform and the repositories reachable by its effective identity.

A review of account settings alone cannot capture the distribution risk described here. The useful question is whether a credential could authorize registry operations under an identity that did not create or approve it. That is the mechanism Docker investigated, and it suggests what an audit of similar conversion flows should examine.

Every credential affected by an ownership transition needs an explicit policy. A migration should state whether it revokes the credential or creates a replacement with a newly approved principal and scope. Preserving the secret while changing its authority would require a security argument that this incident makes difficult to support.

The fix preceded the public explanation

Docker received the report on September 30 and deployed a production fix that afternoon, less than four hours later. The fix removed PAT transfer from account conversion. Docker updated its documentation to require new credentials after conversion and to recommend organization access tokens.

The advisory says Docker notified potentially affected users and organization owners on October 2. On October 8, it deactivated the identified transferred PATs, except where an account holder had asked to retain them. These are separate response actions. Stopping future transfers does not itself invalidate credentials transferred before the fix.

Docker's exposure window ends with the September 30 fix. The notification and deactivation dates distinguish service remediation from handling previously issued credentials. Those distinctions matter when determining which records to examine.

The current conversion instructions say PATs from the converted account stop working and direct the new owner to create an organization access token. That makes the credential transition visible to the operator. An automation migration should plan for that replacement and validate that the resulting token represents the intended organization.

The investigation has stated limits

Docker says it enumerated every conversion since the flaw's introduction and correlated those records with registry authentication logs, usage data, and token records. It examined approximately 304,000 pushes made with transferred tokens. Its reported result was no evidence of exploitation.

The advisory provides more detail than that phrase alone. It says those pushes went to the converted organization's repositories or the new owner's repositories. Docker also analyzed the highest-risk public images without executing them and found no malicious content in that analysis. Those findings describe the investigation performed, and they should remain attributed to Docker.

The same advisory acknowledges an observability limit. Registry logs show token use, so an unused transferred token leaves no use record. Docker therefore treated all PATs moved through the vulnerable flow as potentially affected, whether or not they appeared in authentication activity.

I consider that a useful distinction between exposure and observed exploitation. An absence of recorded malicious use does not establish that the credential never existed. The affected population came from the ownership transition, while the use records helped assess what happened afterward.

Docker also states that users who did not receive its notification were not exposed through this flow and need take no action for this advisory. That scoped guidance does not support an indiscriminate incident claim. A routine credential review can still be reasonable policy, but it should be explained independently from whether Docker identified an account as affected.

Ownership transitions need explicit credential rules

Beyond the immediate fix, Docker says it is requiring consent before a user becomes an organization owner and notifying them afterward. It also describes recording an auditable history of token ownership changes and reviewing other flows for the same pattern. Those changes address both authorization and the evidence needed to investigate transitions.

My own review question would be whether any remaining migration operation can change a credential's effective principal without the receiving principal's approval. That question applies to service identities as well as personal accounts. The token's scope should also be examined after any transition, since ownership and permissions jointly determine what its holder can do.

For organization automation, I support the advisory's recommendation to use organization access tokens. The reason is the explicit relationship between the automation and the organization whose repositories it needs. A credential replacement after conversion should validate that relationship, including the repository operations the automation is allowed to perform.