Docker has disclosed a critical Docker Hub vulnerability that could let an attacker impersonate another registry user and publish container images under trusted repository names. The flaw, CVE-2026-105445, stemmed from how personal access tokens were handled when a personal account was converted into an organization.

Docker deployed a production fix on September 30, 2026 and says its investigation found no evidence that the weakness was exploited. Even without confirmed abuse, the possible outcome was serious: a malicious image pushed through an apparently legitimate identity could reach build pipelines and downstream users that trust that repository.

Token ownership changed without the secret changing

Docker Hub lets a user convert a personal account into an organization while preserving repository names. During the process, the user selects an existing account to become the new organization’s owner. Beginning August 26, 2024, the conversion also transferred the original account’s personal access tokens, or PATs, to that owner.

The platform changed the ownership record but did not rotate or revoke the underlying token secret. The selected owner was not required to approve the transfer and did not receive a notification. That mismatch created an impersonation path: an attacker could create an account and PAT, convert the account into an organization, and assign an intended victim as owner. The attacker still possessed the secret, but Docker Hub now associated it with the victim.

Registry requests made with the token could then authenticate as the target user. Depending on the token scope and that user’s permissions, the attacker might pull, push or delete images in personal repositories and organizations to which the victim had access.

Serious registry impact, but not full account takeover

The vulnerability affected registry operations rather than the Docker Hub website. It did not let an attacker change the victim’s password, email address or multifactor authentication settings. The practical reach depended on the transferred token’s scope and the permissions attached to the identity it acquired.

That boundary matters, but it does not eliminate supply-chain risk. Replacing a widely consumed image or publishing a malicious version under a trusted namespace could introduce unexpected code into automated deployments. Teams that pull mutable tags without signature or digest verification would face greater exposure than teams enforcing provenance controls.

Docker’s investigation and remediation

Researchers Peter Molnar and Krisztian Hozak of mptrdev.com reported the problem through Docker’s vulnerability disclosure program. Docker says it reproduced the issue with test accounts and released a fix in under four hours. The exposure window ran from August 26, 2024 until approximately 19:10 UTC on September 30, 2026.

The company reviewed account conversions across that period and examined registry authentication, token records and usage. Around 304,000 image pushes used transferred tokens, but Docker says all went to repositories owned by the converted organization or its new owner. Its review of higher-risk public images found no signs of malware, cryptomining, credential theft, persistence or tampering.

Because logs record token use rather than every existing token, Docker treated all transferred PATs as potentially affected. It notified exposed users and organization owners on October 2, then deactivated transferred tokens on October 8 unless an owner asked to retain one. Account conversion no longer transfers PATs, and Docker is adding owner consent, notifications and stronger records around ownership changes.

Steps Docker Hub users should take

• Review personal access tokens and revoke any that are unfamiliar, unused or broader than necessary.
• Use organization access tokens for organizational automation instead of tying critical workflows to personal identities.
• Audit image publishing history, repository permissions and recent changes to important tags.
• Pin production dependencies by digest where practical and verify image signatures or provenance.
• Rebuild credentials in CI/CD systems when a token may have been transferred or exposed.

Docker says users who did not receive a notification were not exposed and need no incident-specific action. General credential hygiene and image verification are still worthwhile because they reduce the effect of future registry or publisher compromises.

A design lesson for automated platforms

CVE-2026-105445 was not a stolen-password bug. It was a lifecycle failure: a credential secret survived while the identity bound to it changed. Platforms that support account conversion, mergers or ownership transfer should invalidate credentials by default, require consent from the receiving owner, and create an auditable record of the change.

Cyber Security News reports that Docker found no malicious use after a broad review. That outcome is encouraging, but the flaw remains a useful warning for software supply chains: trusted names are not enough. Strong token governance, immutable references and verifiable provenance provide the additional assurance needed when registry identity controls fail.