Docker closes critical Hub token-transfer vulnerability
Docker has fixed CVE-2026-105445, a critical Docker Hub vulnerability that could allow one user to push, pull or delete container images at the registry under another user's identity. The issue, dubbed GhostPat by researchers Peter Molnar and Krisztian Hozak of mptrdev.com, was present from August 26, 2024 until Docker deployed its fix on September 30, 2026.
Docker assigned the flaw a CVSS 4.0 score of 9.4. It said it found no evidence of exploitation after reviewing account conversions, token records and registry activity. The remediation was made on Docker Hub, so customers do not need to install an update.
How transferred tokens could retain registry access
The problem affected the process for converting a personal Docker account into an organization. Because Docker Hub cannot directly move a repository between accounts, a user can convert the personal account, retain its name and designate an existing account as the organization owner.
During the affected period, that conversion changed the owner recorded for the personal access tokens, or PATs, while leaving their secrets unchanged. A token created by an attacker on an account they controlled could therefore continue to authenticate to the registry as the person named as the new organization owner. That person was neither asked to approve the designation nor notified, Docker and the reporting researchers said.
Access was restricted to the registry rather than the Docker Hub web interface. It could not change passwords, email addresses or two-factor settings, and could not take over an account. Within the token's assigned permissions, however, it could pull from private repositories, push images to repositories available to the named owner, or delete images. Docker classified the issue as critical because it could enable publication of images under a legitimate name.
Docker's review and token response
Docker said it examined every account conversion during the exposure window, looking for tokens used under more than one identity and reviewing every push made through a transferred token. That review covered about 304,000 pushes. Docker said each was sent to a repository belonging to the converted organization or its named owner, and that in most cases both accounts belonged to the same person or team.
For cases in which common control could not be confirmed, the company examined the highest-risk public images without running them and reported finding no malware or tampering. Registry logs record token use rather than the existence of a token, however, so a transferred token that was never used would leave no activity record. Docker consequently treated every token moved through a conversion as potentially affected.
On October 2, Docker emailed users whose accounts had received transferred tokens and the relevant organization owners. The notices identified tokens by description and creation date. Docker described the affected population only as a limited number of users, and said people who did not receive an email were not exposed. On October 8, it deactivated identified transferred tokens, except those their owners had requested to retain.
What teams should verify
Docker advises users to review the Personal access tokens section in Account settings and revoke tokens they do not recognize or no longer need. Token descriptions are not conclusive because the creator chooses them; an unfamiliar token, regardless of its name, is a relevant warning sign. Users should also check the account switcher for organizations they do not remember joining.
For automation owned by an organization, Docker recommends organization access tokens instead of an individual's PAT. Those tokens require Docker Team or Docker Business and can be managed by authorized organization roles. Eligible organization owners can also inspect activity logs for past pushes, including tags and the token used; Docker Home retains those logs for 30 days, with older entries available through the Docker Hub API.
Docker now requires consent before naming a user as an organization owner, sends that user a notification and records every token ownership change. For businesses, the immediate implication is to treat registry credentials as supply-chain controls: inventory tokens, validate ownership changes and move shared build automation away from personal credentials.