GhostPat Changed Who a Docker Hub Token Belonged To

A Docker Hub personal access token did not need to be stolen to become dangerous. For a little over two years, an account-conversion flaw could change who the token belonged to while its secret stayed in someone else’s hands.

Docker calls the issue CVE-2026-105445. Security researchers reported it on September 30, 2026; Docker says it reproduced and fixed the flaw that afternoon. The vulnerability was disclosed publicly on October 12, and the NVD record followed on October 13.

This is a source-based analysis of Docker’s advisory, the NVD record, and Docker’s current account-conversion guidance. WealthLab did not reproduce the vulnerability or test Docker Hub accounts.

The unusual part was ownership, not token theft

Docker Hub preserves repository names when a personal account is converted into an organization. That matters because an image such as alice/app can remain at the same registry path after alice becomes an organization.

From August 26, 2024 until September 30, 2026, the conversion flow also reassigned the converted account’s personal access tokens to the user named as the new organization owner. The token secret was neither rotated nor revoked. Docker says the named owner was not asked to consent and was not notified.

That combination created the attack path:

1. An attacker created an account and a PAT whose secret they retained.
2. They converted the account into an organization and named another Docker Hub user as owner.
3. Hub changed the token’s ownership record to that user without changing the secret.
4. The retained secret then authenticated to the registry as the target, within the token’s scope.

The NVD classifies the flaw as CWE-266, Incorrect Privilege Assignment. That label is useful: the failure was not a weak token format or a leaked password. It was an identity transition that preserved a credential while changing the authority attached to it.

Why this became a software-supply-chain risk

A reassigned PAT could potentially pull, push, or delete images in repositories accessible to the target user, subject to the token’s scopes. A malicious push under a trusted repository name is especially consequential because downstream deployments may continue pulling that name without realizing the publisher changed.

Docker rated the issue critical. The company also drew a boundary around the impact: the token did not provide access to the Hub web interface and could not change the target’s password, email address, or two-factor-authentication settings. This was registry impersonation, not complete account takeover.

The distinction should shape incident response. Reviewing only web-login history would miss the relevant activity. Registry authentication, image pushes, immutable digests, deployment records, and build provenance are the better evidence sources.

Docker found no exploitation, but that is not proof of absence

Docker says it reviewed every account conversion since the flaw was introduced, correlated IAM and registry records, and examined roughly 304,000 pushes made with transferred tokens. It reported no evidence that the vulnerability was exploited and no evidence that Docker infrastructure was affected.

The advisory is also explicit about the evidence limit: registry logs can show when a token was used, but they cannot show that an unused token secret exists. A transferred token that was retained but never exercised would leave no registry-use trail. Docker therefore treated all tokens transferred through this flow as potentially affected rather than relying only on detected misuse.

That is the right way to read “no evidence of exploitation”: it describes the reviewed telemetry, not a mathematical guarantee that no secret was ever retained.

Who actually needs to respond

Docker says it emailed affected users and organization owners on October 2 with the subject “Docker Hub Vulnerability Identified & Resolved.” It deactivated identified transferred PATs on October 8, except where an account holder had opted to keep one. Docker’s guidance is unusually direct: if you did not receive that notice, it says your account was not exposed through this conversion flaw and no vulnerability-specific action is required.

That does not make routine token hygiene unnecessary. It means teams should avoid turning a bounded incident into an indiscriminate emergency rotation. The most useful response depends on evidence:

• Notified organization: identify the named tokens, confirm their deactivation or deliberate retention, review registry activity during the exposure period, and compare important tags with known-good digests and build records.
• Account converted during the exposure window: preserve the conversion date and ownership history, then reconcile it with Docker’s notification and PAT inventory.
• No notice and no relevant conversion: perform ordinary stale-token cleanup, but do not claim this CVE exposed the account.

For a suspicious push, avoid trusting a mutable tag alone. Record the current digest before remediation, compare it with CI output or signed provenance, identify deployments that consumed it, and preserve logs before deleting or overwriting evidence.

The long-term fix is to stop making people the automation boundary

Docker removed PAT transfer from account conversion. Its updated model requires tokens to be recreated after conversion, and Docker recommends organization access tokens for automation that belongs to an organization.

The broader lesson is architectural. A person’s PAT accumulates whatever repository access that person gains over time. It also follows the person through role changes, offboarding, and organization membership. An organization-scoped automation identity makes ownership and revocation easier to reason about.

That does not mean “organization token” automatically equals “safe.” The token still needs minimum scopes, a documented owner, rotation, secret-manager storage, and removal from logs and build artifacts. Where a CI platform and registry support short-lived federation, it can further reduce long-lived-secret exposure; it does not remove the need to constrain repository and workflow permissions.

A control-plane change deserves a control-plane review

Account conversion looks like an administrative convenience, but it changes namespaces, owners, credentials, and the authority behind a widely pulled artifact. Treat it like a migration:

• inventory repositories, collaborators, tokens, webhooks, automated builds, and deploy keys before the change;
• revoke or replace personal credentials rather than assuming they will follow the intended owner safely;
• pin critical deployments by digest during the transition;
• verify push and pull behavior from the intended automation identity afterward; and
• retain enough registry and CI history to connect an image digest to its source revision and build.

Docker says it is adding owner consent, owner notifications, auditable token-ownership history, and reviews of other credential-ownership transitions. Those measures address the class of failure more directly than another reminder to keep secrets private.

What this incident does not show

This advisory does not establish that public images were compromised, that every Docker Hub PAT was exposed, or that self-hosted Docker Engine was vulnerable. It concerns Docker Hub’s account-to-organization conversion flow during a defined period. The NVD entry was still awaiting enrichment when reviewed on November 1, 2026, so WealthLab is not substituting an unofficial score for NIST’s pending assessment.

It also does not prove that every registry needs the same remediation. The portable lesson is narrower: whenever an identity changes owners, namespaces, or tenancy, verify whether its credentials are revoked, rotated, transferred, or silently preserved.

Bottom line

CVE-2026-105445 was fixed quickly after disclosure, affected users were notified, and Docker says its review found no exploitation. The valuable part of the incident is the failure mode it exposes: a valid credential can become an impersonation tool when the system changes its owner without changing its secret.

For teams that publish containers, registry identity is part of the software supply chain. Token ownership, image digests, provenance, and account migrations belong in the same threat model as the code inside the image.

Sources and evidence date

• Docker, Docker Hub security advisory: personal access tokens transferred during account-to-organization conversions, published October 12, 2026.
• NIST NVD, CVE-2026-105445, published October 13 and last modified October 19, 2026.
• Docker Docs, Convert an account into an organization, reviewed November 1, 2026.

Evidence reviewed November 1, 2026. This article contains no affiliate links.