Docker Hub Fixes Critical Token Transfer Flaw in CVE-2026-105445
Docker disclosed a critical Docker Hub vulnerability that could transfer personal access tokens during account-to-organization conversions. The company has deployed a fix, deactivated affected tokens, and reported no evidence of exploitation.
Xcademia Team
Docker has disclosed a critical security vulnerability in Docker Hub that could allow personal access tokens to remain usable by their original holders after being transferred to a new account owner.
Tracked as CVE-2026-105445, the flaw affected Docker Hub's identity and access management during conversions from personal accounts to organizations.
In a security advisory published on October 12, 2026, Docker explained that the issue could allow a token created by one account to authenticate against the Docker registry with the permissions of another user. This created a potential software supply chain risk because the token could be used to pull, push, or delete container images within its permitted scope.
Docker says it deployed a fix on September 30, 2026, and investigated account conversions dating back to when the vulnerability was introduced. The company reported finding no evidence that the flaw had been exploited.
What Is CVE-2026-105445?
CVE-2026-105445 concerns the way Docker Hub handled personal access tokens during account-to-organization conversions.
Docker Hub allows users to convert personal accounts into organizations. This process helps users move toward organization-owned repositories while preserving existing repository names and references.
However, Docker disclosed that beginning on August 26, 2024, the conversion process also reassigned personal access tokens to the account designated as the new organization's owner.
The problem was that the process changed the token's ownership record without rotating or revoking its secret. The designated owner was also not required to approve the transfer and was not notified.
As a result, the original token holder could retain the secret while the token operated with the new owner's registry permissions.
Docker classified the vulnerability as critical because it could potentially allow unauthorized changes to container images published under legitimate account or organization names.
How the Docker Hub Token Vulnerability Worked
The vulnerability involved a sequence of actions during account conversion:
An attacker creates a Docker Hub account and generates a personal access token.
The attacker converts that account into an organization and designates another user as its owner.
Docker Hub transfers the token's ownership record without changing the secret.
The attacker retains the original secret, while the token authenticates with the designated owner's registry permissions.
The potential impact depended on the permissions associated with the token and the resources available to the designated owner.
What Could an Attacker Do?
According to Docker, a reassigned token could potentially allow an attacker to perform registry operations within the token's scope.
These operations included:
Pull container images: Access images available to the affected identity.
Push container images: Publish or modify images within the token's authorized scope.
Delete container images: Remove images from repositories where the token had sufficient permissions.
The most serious concern was the possibility of publishing a modified or malicious container image under a legitimate account or organization name. Developers and automated deployment systems might then retrieve an image they believed came from a trusted source.
This is why Docker treated the issue as a software supply chain risk.
However, Docker clarified that the vulnerability did not provide access to the Docker Hub web interface. It also could not be used through this flaw to change the affected user's password, email address, or two-factor authentication settings, or to take over the account itself.
Which Accounts Were Potentially Affected?
Docker identified the exposure window as beginning on August 26, 2024, and ending when the production fix was deployed on September 30, 2026.
The company reviewed account conversions performed during this period and correlated them with registry authentication logs, usage data, and identity and access management token records.
Docker examined approximately 304,000 image pushes made using transferred tokens. It reported no evidence of exploitation.
The investigation found that the examined pushes went to repositories belonging to the converted organization or the new owner. None went to an unrelated user's or organization's account.
Docker also statically analyzed the highest-risk public images identified during its review. The company reported finding no malware, cryptominers, command-and-control activity, credential harvesting, persistence, or tampering in those images.
Docker further stated that it found no evidence that its own infrastructure or services had been affected.
These findings should be understood within the limits of the investigation. Docker noted that registry logs record token usage rather than the existence of unused tokens. A transferred token that was never used would leave no usage record. Consequently, the company treated all tokens transferred through the affected process during the exposure window as potentially affected, regardless of whether logs showed them being used.
How Docker Responded to the Vulnerability
Docker said it received the vulnerability report on September 30, 2026, through its Vulnerability Disclosure Program. The company reproduced the issue internally and deployed a fix that afternoon, less than four hours after receiving the report.
Its response included several actions.
1. Removing Token Transfers During Conversion
Docker changed the account conversion process so that personal access tokens no longer transfer to the new owner. The new owner must create their own tokens when needed.
2. Notifying Potentially Affected Users
On October 2, Docker emailed users whose accounts had received transferred tokens. The notifications included token descriptions and creation dates to help recipients identify the relevant credentials. Associated organization owners were also notified.
3. Deactivating Identified Tokens
On October 8, Docker deactivated the identified tokens that had been transferred through the affected process, except for tokens whose owners had requested that they remain active before the deadline.
4. Improving Ownership Controls and Auditing
Docker also outlined further changes:
Requiring user consent before someone is designated as an organization owner.
Notifying users when they are named as an owner.
Recording an auditable history of token ownership changes.
Reviewing other credential ownership workflows for similar weaknesses.
These measures address both the immediate token transfer issue and the processes surrounding identity, authorization, and credential lifecycle management.
What Docker Hub Users Should Do
Docker stated that users who did not receive its October 2 notification were not exposed through this particular vulnerability and did not need to take action for this issue.
Users who received the notification should follow Docker's instructions and review the token details provided in the email.
Docker recommends that users review personal access tokens under Docker Hub Account Settings → Personal Access Tokens and revoke credentials they do not recognize or no longer use.
For automation associated with an organization, Docker recommends using organization access tokens rather than relying on an individual's personal access token.
Why This Vulnerability Matters for Software Supply Chain Security
The Docker Hub incident highlights a broader security principle: changing the owner of a credential is not the same as transferring control of the credential itself.
A token can provide access to important resources without granting access to the account's normal web interface. If ownership records change but the original secret remains valid, the system may unintentionally preserve access for a party that should no longer possess it.
For organizations using container images in development and deployment pipelines, this distinction matters. Container images often serve as building blocks for applications, and unauthorized changes to trusted images can introduce risks further along the software delivery process.
The incident also demonstrates why credential management requires more than authentication checks. Systems need reliable ownership verification, appropriate consent, clear notification mechanisms, and auditable records of credential changes.
For security teams, the case reinforces the importance of reviewing how access tokens behave during account migrations, ownership transfers, organizational restructuring, and automation changes.
These broader lessons are analysis based on the disclosed vulnerability, rather than additional claims about Docker's products or customer environments.
Conclusion
CVE-2026-105445 exposed a weakness in Docker Hub's account-to-organization conversion workflow, where personal access tokens could be reassigned without changing their underlying secrets. Depending on the token's permissions, this could have allowed its original holder to perform registry operations under another user's identity.
Docker reports that it fixed the issue on September 30, notified potentially affected users, deactivated identified transferred tokens, and found no evidence of exploitation during its investigation.
For Docker Hub users, the key takeaway is to review credential ownership carefully, follow any security notifications received from Docker, and use organization-scoped credentials for organization automation where appropriate.
Source: Docker Official Blog
About the Author