Key takeaways
- in Docker Hub that silently transferred personal access tokens during account conversions.
- The issue enabled an attacker to maintain an active token operating with the target owner’s registry permissions without consent or notification.
- Docker confirmed that a retroactive audit of 304,000 image pushes found no evidence of unauthorized activity or supply chain tampering.
- Transferred tokens were systematically deactivated on October 8, 2026, and conversion flows now require explicit owner consent.
Docker has resolved a critical Identity and Access Management (IAM) vulnerability in Docker Hub, tracked as CVE-2026-105445 and dubbed “GhostPat,” that allowed personal access tokens (PATs) to transfer silently to new organization owners during account conversions. Originally introduced in August 2024, the flaw enabled an external user to create a personal token on a disposable account, convert that account into an organization naming a target user as owner, and retain an active credential that authenticated against container registries under the target’s identity. Docker deployed a production fix within four hours of receiving a responsible disclosure report on September 30, 2026, and confirmed that a retrospective review of 304,000 pushes found no evidence of malicious exploitation.
The security advisory, issued by Docker Chief Security Officer Mark Lechner, addresses research reported by Peter Molnar and Krisztian Hozak of mptrdev.com, who documented the exploit on ghostpat.com. Because the transferred access tokens permitted pushing and pulling images under established namespaces, Docker classified the issue as a critical software supply chain risk.
Silent token reassignment in account conversions
The flaw resided in Docker Hub’s account-to-organization conversion workflow. Converting a personal namespace into an organization is standard practice for growing projects: it allows an existing image repository path to become organization-managed without breaking downstream automated build systems or user pulls referencing the original location. During this conversion, the initiating account designates an existing Docker Hub user as the new organization’s owner.
Beginning August 26, 2024, the platform altered its internal IAM behavior by automatically reassigning the converting account’s existing personal access tokens to the newly appointed owner. This transfer occurred at the database record level without invalidating, rotating, or regenerating the underlying secret value. Crucially, the platform did not prompt the named owner for confirmation or notify them of the incoming credential assignment. These compounded oversights made a repeatable privilege-transfer attack possible:
- An attacker registered a disposable Docker Hub personal account and generated a personal access token configured with read, write, and delete permissions.
- The attacker initiated an account conversion into an organization, specifying an arbitrary target user as the new organization owner.
- Docker Hub reassigned the database ownership record of the personal access token to the target user without rotating the secret or dispatching a confirmation notice.
- The attacker retained the unrevoked token secret, which now authenticated against the Docker registry using the target user’s active authority and scope.
Scope of access and supply chain investigation
The blast radius of a transferred token was concentrated on registry operations. A reassigned token could authenticate against Docker Hub’s registry API using standard Docker CLI tooling, enabling an attacker to pull private repositories, push new tags or modified image layers, and delete tags across repositories owned by the target or accessible through the target’s organizational memberships. For software supply chains, the ability to publish untrusted container images under a trusted maintainer’s name represents an immediate vector for upstream tampering.
However, the flaw carried specific structural limits. Reassigned PATs could not authenticate to the Docker Hub web interface, nor could they modify email addresses, change passwords, adjust two-factor authentication configurations, or achieve full account takeover. The exposure window extended from August 26, 2024 at 20:33 UTC until Docker deployed the production mitigation on September 30, 2026 at approximately 19:10 UTC.
Following the patch, Docker’s security team audited every account conversion executed during the 25-month window. Engineers analyzed approximately 304,000 container image pushes executed using transferred tokens, confirming that every push landed either in the converted organization’s repositories or in the new owner’s repositories. Static analysis of public container images pushed after conversions where dual control could not be confirmed revealed no presence of malware, cryptominers, command-and-control backdoors, or credential harvesting payloads. Docker noted that access logs record active token usage rather than latent existence, prompting the vendor to treat all transferred tokens as potentially exposed regardless of log activity.
This incident reflects broader governance challenges surrounding delegation and identity boundaries across modern platforms, similar to issues where invisible SaaS identity risks and credential delegation bypass traditional boundary controls.
Remediation timeline and token deactivation
Docker addressed the report under a coordinated vulnerability disclosure process, moving from initial notification to production remediation in less than four hours. The immediate patch decoupled personal access tokens from the conversion flow entirely.
| Date and Time (EDT) | Operational Action | Status and Impact |
|---|---|---|
| Sept 30, 11:40 AM | Vulnerability report received | External researchers submit proof-of-concept to security team |
| Sept 30, ~1:30 PM | Internal reproduction completed | Engineers confirm credential transfer behavior in test accounts |
| Sept 30, ~3:10 PM | Production mitigation deployed | Account conversion flow stripped of token reassignment mechanism |
| Sept 30, ~3:23 PM | Documentation revised | Guidance updated to state that PATs do not transfer across accounts |
| Oct 2, 5:30 PM | Direct user notifications issued | Email sent to exposed users listing token descriptions and creation dates |
| Oct 8, 3:45 PM | Automated token deactivation | Forced invalidation of all transferred PATs, excluding explicit opt-outs |
On October 2, Docker notified exposed account holders and organization administrators by email, listing specific token descriptions and creation dates. On October 8 at 3:45 PM EDT, Docker executed a forced deactivation of all identified transferred PATs, exempting only those tokens whose owners actively requested retention prior to the deadline.
What happens next
Docker is enacting platform adjustments to prevent credential inheritance flaws. The platform now requires explicit affirmative consent from any user designated as an organization owner prior to the assignment taking effect, accompanied by direct transactional notifications. Additionally, Docker is deploying an auditable event ledger for token ownership transitions and reviewing secondary account workflows that manipulate authentication credentials.
For enterprise IT leaders and DevSecOps practitioners, the advisory highlights essential operational steps:
- Audit Existing Personal Tokens: Teams should review all personal access tokens under Docker Hub Account Settings, revoking any credentials with unfamiliar creation dates or descriptions.
- Migrate CI/CD Pipelines to Organization Access Tokens: Continuous delivery pipelines and shared build infrastructure should rely on Organization Access Tokens rather than individual PATs to enforce scoped access boundaries and prevent credential inheritance risks.
- Implement Centralized Credential Governance: Platform teams should regularly cross-reference registry authentication logs with identity provider records and enforce routine secret rotation.
