www.it-connect.fr
GhostPat: Critical Docker Hub Flaw Let Attackers Impersonate Any User
In late September 2026, Docker fixed GhostPat, a security flaw affecting identity management directly on Docker Hub. Here’s what we know about this CVE-2026-105445 issue.
On October 12, 2026, Docker published a security bulletin dedicated to vulnerability CVE-2026-105445, a vulnerability affecting identity and access management on Docker Hub. It was discovered by two researchers, Peter Molnar and Krisztian Hozak, who dubbed it GhostPat.
Before discussing this flaw, here is a quick reminder: Docker Hub is the registry used to store, share, and download container images. To authenticate a tool or workflow, a personal access token (PAT) is usually used. Depending on its scope, this token can pull, push, or delete images.
The GhostPat security issue lies in a very specific feature: converting a personal account into an organization. In reality, Docker Hub cannot move a repository from one account to another. The conversion is therefore used to transfer repositories from an account under the ownership of an organization, without breaking the docker pull commands that reference them. As a result, to allow this transition from one account to another, the user designates an existing Docker Hub account as the owner of the new organization.
How does the GhostPat flaw work?
Since August 26, 2024, this conversion also transferred the account's PATs to the new owner. Docker simply changed the owner of the token without revoking it or changing its secret. And the designated owner had nothing to approve: no confirmation, no notification.
The attack scenario, described by both Docker and the researchers, can be broken down into four main steps:
- Preparation: the attacker creates a disposable account and generates a PAT.
- Conversion: they convert this account into an organization and designate the target as the owner. Any existing username will do.
- Transfer: the PAT is reassigned to the target's account, but the attacker still holds the secret.
- Impersonation: the token now authenticates to the registry as the target, including within organizations where they are a member.
The flaw is truly serious because, by exploiting it, an attacker could pull, push, or delete images in the victim's repositories and in the organizations they had access to. During their tests, the researchers were even able to retrieve the targeted user's private repositories. Most importantly, the attack cost is effectively zero: all it takes is creating a free account and clicking a few times in the Docker Hub web interface.
"Anyone with a free Docker account can do it", they summarize on the dedicated GhostPat website. This vulnerability therefore poses a real supply chain risk, as it makes it possible to publish images under a legitimate name. At Docker, this flaw was classified as critical.
No exploitation detected
This flaw was reported to Docker on September 30, 2026, through its Bug Bounty program. Docker's team responded quickly, as the fix was released a few hours later, even though the flaw had been present for more than two years. From now on, converting an account no longer transfers any PAT.
Docker then reviewed all such conversions performed since August 26, 2024, correlating registry authentication logs with token data. About 304,000 pushes made with transferred tokens were examined. "We found no evidence that the vulnerability was exploited", Docker said. In the vast majority of cases, the converted account and the designated owner account belonged to the same person or the same team.
As a precaution, exposed users, whose number was not disclosed, were notified by email on October 2. And to make sure there were no unpleasant surprises following the disclosure of this flaw, Docker made a decision: on October 8, those tokens were disabled, except for those their owners had asked to keep.
Finally, it turns out that Docker also tightened the transfer mechanism, in addition to fixing the flaw. Indeed, user consent will now be required before designating them as the owner of an organization, and every token ownership change will be logged (logs had previously been limited to token usage once the transfer had taken place).
