- Docker Hub's account-to-organization conversion re-assigned personal access tokens to a named owner without consent, so an attacker could act as that user at the registry.
- Docker says it found no evidence of exploitation, but registry logs cannot show tokens that were never used, so it treated every transferred token as potentially affected.
- Review personal access tokens on your Docker Hub account, revoke any you do not recognise, and use organization access tokens for automation.
A secret is worth only what the system believes about its owner. A Docker Hub flaw changed that belief and left the secret alone. The token stayed the same. The name attached to it changed.
Docker tracks the flaw as CVE-2026-105445 and rated it critical. Its reasoning was simple. The access included publishing images under a legitimate name. Docker credits Peter Molnar and Krisztian Hozak, who work at mptrdev.com, with spotting the flaw and reporting it responsibly. Their report reached Docker on the morning of September 30, 2026, and a fix was live that afternoon.
How a repository workaround became an identity swap
Docker Hub offers no transfer option for repositories. Users who want a repository to belong to a team convert a personal account into an organization instead. This keeps names such as alice/app working for everyone who already pulls them. At conversion, the user picks an existing Hub account to own the new organization.
Starting August 26, 2024, conversion had a side effect. Every personal access token (PAT) on the converted account moved to the new owner. A PAT is a secret that tools and automation use to sign in. Only the owner label on the token changed. The secret was neither rotated nor revoked. Nobody asked the chosen owner to agree, and nobody told them.
Docker describes four steps for an attack. First, the attacker opens an account and makes a PAT. Second, the attacker turns that account into an organization and picks the victim as its owner. Third, the PAT now belongs to the victim, yet the attacker still knows the secret. Fourth, the token signs in to the registry as the victim.
Within the token's scope, the attacker could potentially pull, push or delete images in the victim's repositories. The same went for organizations where the victim had access. Docker says the flaw gave no entry to the web interface. It could not change the victim's password, email address or two-factor settings.
What Docker found, and what it cannot know
Docker listed every account conversion since August 2024. It matched them against registry sign-in logs, usage data and token records. It hunted for any token seen under two identities. It also went through every push made with a moved token.
Docker found no evidence of exploitation. Each push landed in the converted organization's repositories or in the new owner's. None reached an unrelated account. Most conversions involved one person or team on both sides, which is the normal use of the feature.
Docker also checked the public images it judged riskiest. These were images pushed after a conversion where it could not show one party controlled both accounts. It analysed them without running them. It found no malware, cryptominers, credential harvesting or tampering.
Docker is open about the limit of this finding. Logs record that a token was used. They cannot show that a token existed. A moved token that nobody used would leave no mark. So Docker did not lean on logs to decide who was exposed. It treated every moved PAT as potentially affected.
It emailed the affected users on October 2. It deactivated the moved tokens on October 8. Owners who asked to keep a token before the deadline were excluded.
The lesson: the owner field is part of the secret
Security teams guard token secrets with care. This flaw shows that the owner record matters just as much. Whoever can rewrite that record can turn a token they hold into someone else's authority. The attacker needed neither the victim's password nor any access to the victim's account.
Think of a hotel key card. Guarding the card means little if anyone can ask the front desk to link it to another guest's room. The card is unchanged. It now opens a different door.
The cost falls on the person named. A developer whose automation publishes images would not have been asked. They would not have been told. Customers who pull alice/app trust the name, not the token behind the upload.
Docker has removed token transfer from conversion. It is now requiring consent before a user is named an organization owner, and it will notify them. It is keeping a record of every change of token owner, so questions can be answered from records. It is also checking other features that change who owns a credential.
Questions to put to your team
First, did anyone in your organization receive Docker's October 2 email? Docker says that if you did not get it, no PAT on your account was moved. Second, which build pipelines sign in with a person's PAT instead of an organization access token? Docker advises organization tokens for organization automation. It also advises revoking any PAT you do not recognise or no longer use.
Third, can you tell who owns each credential today? Can you see how that ownership might change? Docker is adding an ownership history now, after the fact. Ask whether your own systems keep one before an incident.
Fourth, Docker's method centred on pushes and on tokens seen under two identities. If you hold private images, ask Docker Support what the review covers for reads and deletions.
A password proves someone holds a secret. The ownership record says whose secret it is. That record deserves the same scrutiny.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Docker.
