Docker Hub flaw let tokens act as other users
A Docker Hub flaw allowed personal access tokens to act as another user at the container registry, giving the token holder the ability to push, pull or delete images within the permissions of the affected account. Docker fixed the issue on September 30 and said it found no evidence that the vulnerability was exploited.
Docker Hub is the registry used to publish and download container images, which are packaged software components commonly used by development teams, hosting providers and cloud services. Docker said the issue was in the process that converts a personal account into an organization. During that conversion, personal access tokens, often shortened to PATs, were transferred to the account named as the new organization owner. A PAT is a secret used instead of a password when software connects to the registry, and Docker said the person who originally created each token could still use it.
The problem was limited to registry access. Docker said it did not give access to the Docker Hub web interface and could not be used to change an account password, email address or two-factor authentication settings. It also could not be used to take over an account through those web settings. The impact was still serious because a transferred token could work as the named owner at the registry, depending on the token's permission level.
Docker tracks the vulnerability as CVE-2026-105445 and rated it critical. The CVE record published on October 13 assigns it a CVSS 4.0 score of 9.4. Docker said the flaw existed from August 26, 2024 until the fix, a period of a little over two years. The fix was applied directly to Docker Hub, so users do not need to install a software update to receive the platform-side correction.
The mechanics matter for any team that relies on container images in build or deployment pipelines. Docker Hub does not move a repository from one account to another. Instead, a user can convert a personal account into an organization that keeps the same name, while naming an existing account as the owner. While the flaw was present, that conversion changed the recorded owner for each PAT but left the secret unchanged. In practical terms, a token created by one person could become accepted by the registry as if it belonged to the newly named owner.
Docker and the researchers who reported the flaw said the named owner was not asked to approve the change and was not notified. Docker's conversion page had included wording since at least August 2024 saying that the new owner receives a notification email. The researchers, from mptrdev.com, called the issue GhostPat and said in their technical write-up that they reproduced it twice using consenting test accounts. They said they were able to log in to the registry as the target account, create and push to a repository in that namespace, push to an organization the target belonged to, and pull private repositories.
The possible actions depended on the transferred token's permissions. Within those limits, it could pull images, push images or delete images in repositories owned by the named user and in organizations that user could access. Docker said it considered the flaw critical because the access could include publishing images under a legitimate name. That risk is meaningful for website and infrastructure teams because container images often feed automated deployment systems, and a trusted repository name can carry operational weight.
Docker also pointed to separate incidents in March and April in which attackers used stolen publisher credentials to push malicious Trivy images and malicious KICS images to the publishers' own Docker Hub repositories. Those incidents are not described as exploitation of this vulnerability, but they show why registry credentials and trusted image names are sensitive security assets.
Docker said it reviewed every account conversion made during the affected period and compared the conversions with registry logs and token records. The company looked for tokens used under more than one identity and examined every push made with a transferred token, about 304,000 pushes in total. Docker said it found no evidence that the vulnerability had been exploited.
According to Docker, every reviewed push went to a repository belonging either to the converted organization or to its named owner. In most cases, Docker said both accounts appeared to belong to the same person or team. Where Docker could not confirm that one person controlled both accounts, it analyzed the highest-risk public images without running them and said it found no malware or tampering.
There is an important limit to that review. Docker said registry logs show when a token is used, not merely that it exists. A transferred token that was never used would not appear in those logs. For that reason, Docker treated every token transferred by a conversion during the affected period as potentially affected, whether or not it had been used. Docker's advisory reports its findings for pushes, but it does not state what the company found for pulls or deletions made with transferred tokens, including pulls from private repositories.
On October 2, Docker emailed users whose accounts had received transferred tokens and separately emailed the owners of the organizations involved. The emails listed the relevant tokens by description and creation date. Docker did not state how many users or tokens were included, describing the affected group only as a limited number of users. Docker said anyone who did not receive the email was not exposed and has nothing to do.
Docker deactivated the transferred tokens it had identified on October 8. Tokens that owners had asked to keep were not deactivated. A publisher of the Docker Compose linter compose-lint wrote that he received two emails on October 2, one as an organization owner and one for his user account. He said he rotated two continuous integration tokens and checked signatures on 42 published images, tracing each image to the build run that created it.
Docker advises users to review their personal access tokens, revoke any they do not recognize or no longer use, and use organization access tokens for automation that belongs to an organization rather than one person's PAT. In Docker Hub, users can open Account settings and then Personal access tokens to see when each token was created and when it was last used. The researchers also suggested watching for a token the user did not create, regardless of its description, and for an unfamiliar organization appearing in the account switcher.
Organization access tokens require a Docker Team or Docker Business subscription. Docker says they are managed by an organization owner, a company owner or a custom role with that permission, and that they do not work with Docker Desktop or Image Access Management.