Docker has fixed a critical vulnerability CVE-2026-105445 in Docker Hub that, for more than two years — from 26 August 2024 to 30 September 2026 — allowed an attacker to bind a controlled Personal Access Token (PAT) to another user’s account and perform operations on container images on their behalf. The vulnerability received a score of 9.4 under CVSS 4.0 and a critical severity rating. The patch was applied on the Docker Hub server side; no client updates are required. According to Docker, no signs of exploitation in real-world attacks have been found, but this conclusion is based solely on the vendor’s internal investigation and has not been confirmed by an independent audit.
Vulnerability mechanism
The issue, classified as CWE-266 (incorrect privilege assignment), affected the mechanism for converting a personal Docker Hub account into an organization account. According to the CVE entry, during conversion the system automatically transferred all Personal Access Tokens (PATs) to the designated organization owner. The key flaw: the token secret was not changed, and the new owner’s consent was not requested.
The attack scenario looked as follows:
- The attacker creates an account and generates a PAT with the desired access rights.
- They convert their account into an organization, specifying the victim as the owner.
- Docker Hub attaches the token to the victim’s account while keeping the token secret unchanged.
- The attacker uses their PAT to access the registry — the system authenticates them as the victim.
Depending on the token’s permissions and the victim’s rights, the attacker could pull, push, and delete container images in the victim’s repositories, including repositories of organizations to which the victim had access. The access was limited to registry operations: the Docker Hub web interface, password changes, email address changes, or two-factor authentication settings remained inaccessible.
Why it was rated critical
Despite the limited scope of impact, Docker assigned the vulnerability a critical rating because of the threat to the software supply chain: an attacker could publish malicious images under the names of legitimate developers. For context: earlier in 2026 Docker reported cases where stolen publisher credentials were used to upload malicious Trivy and KICS images into their own repositories. GhostPat provided an alternative vector for similar attacks — without the need to steal passwords.
A notable detail: starting in April 2025, Docker’s own documentation explicitly described the transfer of PATs during account conversion as expected behavior. This note was removed on 30 September 2026 — just minutes after the patch was deployed. Thus, for about 17 out of the 25 months the bug existed, the vulnerable behavior was documented as a feature rather than a flaw.
Investigation and response
The vulnerability was discovered by researchers Peter Molnár and Christian Hozak (mptrdev.com), who named it GhostPat. According to The Hacker News, they reproduced the exploit twice on test accounts with the owners’ consent, confirming the ability to log into the registry as the target user, create repositories in their namespace, and access private repositories. Docker, by its own account, deployed a fix less than four hours after receiving the report.
Docker reports that the company reviewed all account conversions over the period during which the bug existed and analyzed around 304,000 image upload operations performed using transferred tokens. According to the vendor, all of these uploads targeted repositories of the converted organization or its designated owner, and in the overwhelming majority of cases both accounts belonged to the same person or team. In cases where this could not be confirmed, Docker analyzed high-risk public images and did not find malicious code. It should be noted that these data have not undergone independent verification, and Docker’s report does not disclose the results of any review of image pull and delete operations.
Practical recommendations
On 2 October 2026, Docker notified users whose accounts had foreign tokens attached, as well as owners of affected organizations. On 8 October, potentially dangerous tokens were deactivated (except for those whose owners explicitly requested retention). According to Docker, users who did not receive a notification do not need to take any action.
For those who did receive a notification or want to perform their own checks:
- Open your account settings → Personal access tokens. Check the creation date and last-used date for each token.
- Revoke tokens that you did not create or no longer use. The token description is set by its creator, so a familiar name does not guarantee legitimacy.
- Check the list of organizations in the account switcher — an unknown organization may be a trace of a conversion.
- For automation at the organization level, use organization access tokens (requires a Docker Team or Docker Business subscription) instead of personal PATs.
- Organization owners on paid plans can review upload history via activity logs (stored for 30 days in the interface, older records are available via the API).
- If you sign images, verify the signatures of published images and compare them with your CI/CD pipeline records.
Docker states that the system now requires explicit user consent before designating them as an organization owner, notifies them of such designation, and logs all token owner changes. The main action for Docker Hub users is to audit their PATs and migrate to organization tokens for any automation related to organizations. For consumers of public images, the incident underscores the importance of verifying image signatures: it is the signature, not the publisher name, that remains a reliable indicator of integrity in the container registry ecosystem.
