A flaw in Docker Hub, the registry where container images are published and downloaded, let one user push, pull, or delete images as another user. Docker fixed the flaw on September 30 and says it found no evidence that anyone exploited it.
The flaw was in the feature that converts a personal account into an organization, Docker said in a security advisory on October 12. Conversion transferred the account’s personal access tokens (PATs) to the user designated as the organization’s owner. A PAT is used in place of a password in the registry, and the person who created each token can still use it.
The access was limited to the registry. It did not reach the Docker Hub web interface, and it could not be used to change a password, email address, or two-factor settings, or to take over an account.
Docker tracks the flaw as CVE-2026-105445 and rated it critical. The CVE record it published on October 13 gives the flaw a CVSS 4.0 score of 9.4.
The flaw was open from August 26, 2024, until the fix, a little over two years. Docker made the fix on Docker Hub itself, so there is no update to install.
Docker Hub cannot move a repository from one account to another. A user instead converts a personal account into an organization that keeps the same name, and must name an existing account as its owner.
Each personal access token acts as the account that owns it, at a permission level chosen when the token is created. While the flaw was open, conversion changed the owner recorded for each token and left its secret unchanged.
An attacker could abuse this by creating a token on an account they controlled, converting that account into an organization, and naming another user as its owner. The token would then work at the registry as that user.
The named owner was not asked to confirm the change and was not notified, according to Docker and the researchers who reported the flaw. Docker’s conversion page has included the sentence “The new owner receives a notification email” since at least August 2024.
Within the token’s permission level, a transferred token could pull, push, or delete images in the named owner’s repositories and in organizations the owner could access.
Docker rated the flaw critical because that access “includes publishing images under a legitimate name,” it said.
In March and April, attackers used stolen publisher credentials to push malicious Trivy images and malicious KICS images to the publishers’ own Docker Hub repositories, according to Docker.
Peter Molnar and Krisztian Hozak of mptrdev.com found the flaw and reported it to Docker, which says it deployed the fix less than four hours after receiving their report. They named the flaw GhostPat.
In their technical write-up, the two say they reproduced the flaw twice on consenting test accounts. They logged in to the registry as the target account, created and pushed to a repository in its namespace, pushed to an organization it belonged to, and pulled its private repositories.
What Docker’s Review Covered
Docker reviewed every account conversion made while the flaw was open and compared them with registry logs and token records. It looked for any token used under more than one identity and examined every push made with a transferred token, about 304,000 in all.
“We found no evidence that the vulnerability was exploited,” the company said.
Every one of those pushes went to a repository belonging to the converted organization or to its named owner, according to Docker. In the large majority of cases, both accounts belonged to the same person or team.
Where it could not confirm that one person controlled both accounts, Docker analyzed the highest-risk public images without running them and found no malware or tampering.
Docker’s registry logs show when a token is used, not that it exists, so a transferred token that was never used left no record in the logs. For that reason, Docker treated every token transferred by a conversion while the flaw was open as possibly affected, whether or not it had been used.
The advisory reports results for pushes. It does not say what Docker found for pulls or deletions made with transferred tokens, including pulls from private repositories.
Who Was Notified and What to Check
On October 2, Docker emailed the users whose accounts had received transferred tokens and, separately, the owners of the organizations involved. Each email listed the tokens by description and creation date.
The advisory does not say how many users or tokens that covers, calling the group only a “limited number” of users.
Anyone who did not receive the email was not exposed and has nothing to do, according to Docker.
On October 8, Docker deactivated the transferred tokens it had identified. Tokens that their owners had asked to keep were not deactivated.
Todd Matens, who publishes a Docker Compose linter called compose-lint, wrote in a blog post that he received two emails on October 2. One was sent to him as an organization owner and the other to his user account. He rotated his two CI tokens and checked the signatures on his 42 published images, tracing each to the CI run that built it.
Docker advises users to review their tokens, revoke any they do not recognize or no longer use, and use organization access tokens, not one person’s PAT, for automation that belongs to an organization.
These details help with those checks:
- Open Account settings, then Personal access tokens. The list shows when each token was created and when it was last used.
- The researchers describe two traces. One is a token you did not create, whatever its name, because whoever creates a token chooses its description. The other is an organization in the account switcher that you do not remember joining.
- Organization access tokens require a Docker Team or Docker Business subscription. They are managed by an organization owner, a company owner, or a custom role with that permission, and they do not work with Docker Desktop or Image Access Management.
- Organization owners on those subscriptions can review past pushes in the activity logs, which record pushed tags and can show the token that pushed them. Docker Home, where the logs are viewed, keeps them for 30 days, and older entries are available through the Docker Hub API.
Docker’s Documentation Described the Transfer
Docker’s own documentation described the token transfer for about 17 of the roughly 25 months the flaw was open. A documentation change on April 22, 2025, added a note to Docker’s conversion page. It said that naming a user as organization owner “will ensure any PATs associated with the user’s account are transferred to the organization owner.”
Docker removed the note on September 30, minutes after the time it gives for the fix. The dates come from the public history of Docker’s documentation, which The Hacker News reviewed.
Docker says it now requires consent before a user is named an organization owner and notifies that user when this happens. It also records every change in token ownership and reviews other features that change who owns a credential.
