Docker Hub's GhostPat flaw let one account mint registry access as another for two years

On October 12, 2026, Docker disclosed CVE-2026-105445, a critical identity and access management flaw in Docker Hub's personal-account-to-organization conversion flow. From August 26, 2024 until September 30, 2026, conversion reassigned the converting account's personal access tokens (PATs) to the newly named organization owner without revoking or rotating the secret. The original token holder could therefore continue using the secret while the registry now treated it as belonging to a different user. Researchers reported the issue on September 30; Docker fixed it in under four hours, notified potentially affected users October 2 and deactivated transferred PATs October 8, except explicit opt-outs.

A Docker Hub namespace and image tag are commonly treated as provenance cues by CI pipelines and downstream users. Here, an attacker could create a token on a disposable account, convert that account into an organization naming a victim as owner, and use the surviving token to pull, push or delete images within the victim's registry permissions. The researchers demonstrated access to private images and writes to a victim namespace and organization repository using consenting test accounts. That is a supply-chain integrity risk even though Docker says it found no evidence the flaw was exploited against real users. The failure mode is broader than Docker: changing credential ownership without changing the underlying secret can silently transfer authority.

Docker Hub allows a personal account to become an organization so its repository names survive ownership changes. From August 2024, that workflow transferred the original account's PAT ownership record to the new owner. The new owner was neither asked to consent nor notified, and the token secret remained valid in the hands of the person who created it. A malicious account holder could therefore create a token first, convert the account, designate another existing user as owner, and then authenticate to the registry as that user. The researchers' GhostPat proof of concept reproduced this on two occasions and tested private-image pulls and pushes using controlled accounts.

The token inherited the target user's available registry scope. Depending on token permissions, that could allow pulling private images, publishing altered images under a trusted namespace, or deleting images in repositories available to the target, including organizations they belonged to. Docker says the flaw did not provide access to its web interface or permit password, email-address or two-factor-authentication changes. The researchers raised a worst-case concern about highly trusted image namespaces, but that scenario was not demonstrated as a real compromise and must not be treated as such.

Docker received the disclosure September 30 and changed account conversion so PATs no longer transfer. It enumerated conversions back to August 26, 2024, correlated registry and IAM records, and reviewed roughly 304,000 image pushes made with transferred tokens. Docker reports no evidence of exploitation and no malware in the higher-risk public images it analysed. It also cautions that a transferred token never used leaves no registry-log trace; its negative finding is not proof that every possible abuse was observable. Potentially affected account holders and organization owners were notified October 2; transferred PATs were deactivated October 8 unless their owner explicitly opted out.

Docker says accounts that did not receive its October 2 notification were not exposed by this specific flaw and need take no incident-specific action. Notified teams should inspect the token descriptions and creation dates Docker provided, review their Docker Hub PAT inventory and registry activity, and revoke tokens they do not recognise or need. Organization-owned CI/CD automation should use organization access tokens rather than tying publishing authority to a person's PAT. Docker has also proposed requiring recipient consent before organization ownership assignment and recording auditable token-ownership history; these are follow-on measures, not all completed controls.