The flaw was open from August 26, 2024, until Docker fixed it on September 30, 2026 — a little over two years — and has been logged as CVE-2026-105445 with a CVSS 4.0 score of 9.4, Docker said in its advisory.
How GhostPat worked — tokens, conversions, and the registry
Docker Hub's account-conversion feature — used to turn a personal account into an organization while keeping the same name and assigning an existing account as owner — transferred personal access tokens (PATs) to the user designated as the organization's owner. Each PAT acts as the account that owns it, at the permission level chosen when the token is created. Conversion changed the owner recorded for each token but left the token's secret unchanged.
Because the registry accepts a token as the identity, an attacker who created a token on an account they controlled, converted that account into an organization, and named another user as its owner could have had that token accepted by the registry as if it belonged to the named owner. 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."
Scope and limits of the access
The vulnerability affected only Docker Hub's registry. Docker said the transferred tokens did not reach the Docker Hub web interface and could not be used to change a password, email address, or two‑factor authentication settings, or to take over an account. The registry logs record when a token is used but do not record that a token exists, which means a transferred token that was never used would leave no log trace.
This site is the portfolio.
OSINTSights runs on Cloudflare Workers, D1, R2, and Vectorize, with an AI pipeline on Hetzner ARM. Nubivance designed, built, and operates it. We do the same for clients.
See what we buildDiscovery, disclosure, and remediation
Researchers Peter Molnar and Krisztian Hozak of mptrdev.com discovered and reported the issue, which they labeled "GhostPat." Docker says it deployed a fix on Docker Hub itself less than four hours after receiving the report. Because the fix was made on the service side, there is no client update to install.
Docker's documentation had described the token transfer for much of the period the flaw was open; a note added on April 22, 2025, stated that naming a user as organization owner "will ensure any PATs associated with the user's account are transferred to the organization owner." That note was removed from the conversion page minutes after Docker applied the fix on September 30, according to the public documentation history reviewed by The Hacker News.
Docker's review and notifications
Docker reviewed every account conversion made while the flaw was open, comparing conversions with registry logs and token records. The company examined every push made with a transferred token — about 304,000 pushes — and searched for evidence that a token had been used under more than one identity. Docker reported finding no evidence that the vulnerability was exploited.
According to Docker, every examined push went to a repository belonging to the converted organization or to its named owner; in the large majority of cases both accounts were controlled by the same person or team. Where Docker could not confirm single ownership, it analyzed the highest‑risk public images (without executing them) and reported finding no malware or tampering. The advisory reports results for pushes and does not say what Docker 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 owners of involved organizations; each email listed tokens by description and creation date. Docker described the set of notified users only as a "limited number." On October 8, Docker deactivated the transferred tokens it had identified, except for tokens that their owners had asked to keep.
What this means for open-source publishers, CI owners, and DevOps teams
- Open-source publishers and maintainers who publish images: Docker's advisory notes past incidents where stolen publisher credentials were used to push malicious Trivy and KICS images. Publishers should review notifications from Docker, verify token provenance, and trace image builds and signatures as Todd Matens did — rotating CI tokens and tracing each published image to the CI run that built it.
- CI and automation owners: The advisory reiterates Docker's recommendation to use organization access tokens (which require Docker Team or Business subscriptions) for automation that belongs to an organization rather than a single person's PAT. Organization access tokens are managed by an organization owner or appropriate custom role and do not work with Docker Desktop or Image Access Management.
- DevOps and security teams: Docker provides practical tools to investigate: Account settings → Personal access tokens shows creation date and last‑used timestamps; activity logs in Docker Home record pushed tags and can show the token that pushed them (logs are kept for 30 days, with older entries available through the Docker Hub API). Because registry logs show use but not token existence, teams should treat any transferred token as potentially affected even if there is no usage record.
Docker says it now requires consent before naming a user as an organization owner, notifies that user when the change happens, records every change in token ownership, and is reviewing other features that change credential ownership. The company also deactivated identified transferred tokens and advised users to review and revoke unrecognized or unused tokens.
Two clear questions remain on the record: whether any transferred tokens were used for pulls or deletions in ways Docker's push analysis did not capture, and how many unique accounts and tokens Docker's "limited number" of notifications covered. Docker's public advisory and the researchers' write‑up together close the technical loop on the vulnerability and the immediate remediation steps; they also underline that credential handling in automation workflows remains a central operational risk.
