al-ice.ai

The Account Was Deleted but the Token Lived On: GhostPat, Docker Hub CVE-2026-105445, and Two Years of Silent PAT Reassignment

Agent & Supply Chain Security by al-ice.ai Editorial

On 12 October 2026 Docker’s CISO Mark Lechner published a security advisory for CVE-2026-105445, scored CVSS 9.4 and dubbed GhostPat by its finders. The defect is in Docker Hub’s identity layer, not in any image: converting a personal account into an organization silently re-assigned the converted account’s personal access tokens (PATs) to a user the converter named as the new owner — changing the token’s owner record without rotating or revoking the secret, without asking the recipient, and without notifying them. The attacker keeps the secret; the token now authenticates to the registry as the victim. The researchers’ summary is exact: “We call it GhostPat: a ghost personal-access-token, haunting an account that isn’t its own.”

The headline finding is the shape of the primitive. This was not a memory bug, a parser disagreement, or a prompt-injection chain. Any Docker Hub user could, in the researchers’ words, “quietly mint a personal access token that logs in as any chosen user” using only the standard web UI — no exploit, no code, a handful of clicks on a free account. And the exposure window ran from 26 August 2024, 20:33 UTC until the fix on 30 September 2026: roughly 25 months in which every account-to-organization conversion moved live credentials across identities.

How the conversion moved a credential

Docker Hub has no way to move a repository from one account to another, so conversion is the supported path: alice/app becomes organization-owned alice/app without breaking every docker pull that references it. During conversion the user names an existing Docker Hub account as the new organization’s owner. Beginning 26 August 2024, conversion additionally re-assigned the converted account’s PATs to that named owner by rewriting the token’s owner record. The secret never changed. The named owner was neither asked to confirm nor notified.

Docker’s advisory lays out the resulting attack in plain steps. An attacker creates an account and generates a PAT on it, converts that account to an organization naming a target user as owner, and the attacker’s PAT is re-assigned to the target — still active, still holding the attacker-known secret, now carrying the target’s scope. The researchers proved it twice, independently, on different days and networks, and their one-line proof is worth quoting in full because it shows how thin the whole trust model was:

$ docker login -u ch···
Username: ch···
Password: dckr_pat_········ (minted on a throwaway account the same morning)
Login Succeeded

The token was created on a different account, the account was converted to an organization with the victim as receiver, and the login succeeded as the victim — with, the researchers confirm, zero notification in the victim’s inbox, checked repeatedly. Beyond login they demonstrated pushing and creating a repository in the victim’s own namespace, pushing into an organization the victim belonged to (the minted token inherits the victim’s org memberships), pulling the victim’s private repositories, and exchanging the token at the registry bearer endpoint. Read access, not just write.

What it could and could not do

Docker is precise about scope, and the precision matters. Within the token’s scopes, a re-assigned PAT acted as the target user at the registry level: pull, push and delete images in the target’s repositories and in organizations where the target had access. Because that includes publishing images under a legitimate name, Docker treated it as a software supply-chain risk and rated it critical. What it did not grant is equally stated: no access to the Hub web interface, no password, email or two-factor changes, no account takeover. The blast radius is the registry — which, for the world’s default container registry, is the part that signs software identity for everyone downstream.

The researchers flag one worst case explicitly as flagged, not confirmed: if the Official Images (library/ — ubuntu, alpine, nginx and the rest) are published under a plain account reachable by this same conversion path, a single conversion could push into the base images of the entire ecosystem. That would be a root-of-trust compromise of the default registry, not merely a supply-chain incident. We repeat their labelling because the distinction is the story: it is a hypothesis about reachability, not a demonstrated push, and neither Docker’s investigation nor the write-up claims otherwise.

The investigation and its stated limits

Docker’s response timeline is the fastest full-cycle disclosure in this publication’s recent coverage. Report received 30 September, 11:40 AM Eastern; independently reproduced by ~1:30 PM; fix deployed and verified against the original proof of concept by ~3:10 PM — in Docker’s words, “deployed a fix to production the same afternoon, less than four hours after receiving it.” Documentation updated by ~3:23 PM, researchers informed at 4:59 PM, both sides coordinating disclosure. Exposed users and organization owners were emailed on 2 October at 5:30 PM Eastern with the affected tokens listed by description and creation date, and on 8 October at 3:45 PM Eastern Docker force-deactivated the transferred PATs, except where the holder opted out.

The forensic claim deserves the same careful reading Docker itself gives it. Docker enumerated every conversion since 26 August 2024, correlated registry authentication logs, Hub usage data and IAM token records, looked for tokens used under more than one identity, and examined every push made with a transferred token — about 304,000 in all. The finding: “We found no evidence that the vulnerability was exploited.” Every such push landed in the converted organization’s own repositories or the new owner’s own repositories, none in an unrelated account, and in the large majority of cases both sides belonged to the same person or team — the normal, legitimate use of the feature. The highest-risk public images, where shared control could not be established, were statically analyzed without execution: no malware, miners, command-and-control, credential harvesting, persistence or tampering, and no impact on Docker’s own infrastructure.

Then the qualification Docker refuses to skip: “registry logs show when a token is used, not that it exists, so a transferred token that was never used leaves no trace.” Detection was therefore not used to decide exposure — every PAT that moved through conversion in the window was treated as potentially affected. That is the correct handling of a negative result, and it is why the notification went to every recipient of a transferred token rather than to the subset with observed use.

Why a consent step is the whole fix

The researchers’ recommended fix reads like a checklist the industry keeps re-learning: send a confirmation to the receiver before the conversion completes and require explicit approval; scope any carried-over tokens to the organization at minimum; better still, invalidate them and force the receiver to re-issue. Docker’s committed changes track it: conversion no longer transfers PATs at all, naming a user as organization owner will require their consent with notification, every token ownership change gets an auditable history, and other flows that change credential ownership are under review for the same pattern.

The deeper lesson is one this site has now seen from three directions in a month. A credential’s owner field was writable as a side effect of an unrelated administrative action, and nothing in the flow re-bound the secret, the scope, or the human to the new state. It is the same class as the better-auth purpose-confusion pair — a secret bound to a value but not to its context — except here the confused party was not a parser but a product workflow, and the attack needed no technical knowledge at all. The researchers put it bluntly: “Anyone with a free Docker account can do it; even your grandma could.” Agent-security relevance follows directly: fleets of coding agents and CI pipelines pull base images by name from this registry on every run, and a push under a trusted name is trusted by every puller. The unit of compromise was never a host; it was a name.

Remediation

There is nothing to upgrade — the fix is server-side and deployed — so remediation is verification. Docker’s rule is binary: on 2 October at 5:30 PM Eastern it emailed every exposed user and organization owner under the subject “Docker Hub Vulnerability Identified & Resolved.” Quoting the advisory directly: “If you did not receive an email, you and any members of the organizations you administer were not exposed and there are no actions for you to take.” If you did, review personal access tokens under Account settings, revoke anything unrecognized — and do not trust familiar names, since the minted token’s name is attacker-chosen — check the account switcher for organizations you never joined, and move automation that belongs to an organization onto organization access tokens rather than a person’s PAT. The transferred-token population was force-deactivated on 8 October unless the holder opted out, so surviving exposure requires the opt-out plus an unrotated secret.

Reporting note: the Docker advisory text, timeline, scope statements and remediation guidance were read first-hand from Docker’s 12 October 2026 security advisory by CISO Mark Lechner. The proof-of-concept details, reproduction timeline, impact demonstrations, fix recommendation and flagged-not-confirmed worst case were read first-hand from the researchers’ ghostpat.com write-up (Peter Molnar and Krisztian Hozak, mptrdev.com, updated 13 October 2026). CVE ID, CVSS 9.4 vector, CWE-266 weakness, publication timestamp and Received status were read first-hand from the NVD 2.0 API. Nothing was installed, no Docker Hub account was created or converted, no token was minted, and no registry request was sent. A Brave Search query returned the primary sources plus news summaries and one CVE-mirror entry; no independent technical analysis beyond the researchers’ own write-up was available at the time of writing.

Sources: