15 OCT 2026 — For just over two years, anyone with a free Docker Hub account could have obtained a working access token for somebody else's account, and the victim would have received no email and no warning. Docker fixed the flaw on 30 September, within four hours of being told about it, and says it has found no sign that anyone used it before then.
The bug sat in an ordinary account feature. It is tracked as CVE-2026-105445 and was nicknamed GhostPat by the two researchers who found it. Docker rated it critical because a stolen token could be used to publish container images under a trusted name.
How a token changed hands
Docker Hub lets a user convert a personal account into an organisation, which is how a project moves its images to a team without breaking every existing pull. During conversion the user names another existing account as the new organisation's owner. According to Docker's advisory, from 26 August 2024 the conversion also reassigned the old account's personal access tokens (PATs) to that new owner. The conversion changed the token's owner record, but the secret itself was never rotated or revoked. The named owner was not asked to confirm and was not told.
That made the attack almost trivial. Create a throwaway account, generate a token, convert the account into an organisation and name the target as its owner. The token, which the attacker still holds, now authenticates to the registry as the target.
What an attacker could do
Within the token's scope, the reassigned PAT acted as the target at the registry level. Docker says that meant an attacker could pull, push or delete images in the target's repositories and in any organisation the target belonged to. "Because that includes publishing images under a legitimate name, we treated this as a software supply chain risk and rated it critical," the company wrote. It could not reach the Docker Hub web interface or change a password, email address or two-factor setting.
The researchers, Peter Molnar and Krisztian Hozak of mptrdev.com, say on their GhostPat site that they reproduced it twice, independently, on different days. They say the minted token logged in, pushed to the victim's own namespace and an organisation the victim belonged to, and pulled the victim's private repositories. They also raise a worst case they label "flagged, not confirmed": if Docker's Official Images, such as ubuntu, alpine and nginx, are published under an account reachable the same way, one conversion could have pushed into base images used across the ecosystem. Docker's advisory does not address that scenario directly.
Docker's evidence, and its limits
Docker says it went through every conversion since August 2024 and examined about 304,000 pushes made with transferred tokens. All of them landed in the converted organisation's own repositories or the new owner's. In most cases the two accounts belonged to the same person or team, which is the normal use of the feature. A static analysis of the riskiest public images found no malware, cryptominers or tampering.
The advisory is clear about the limit. "Registry logs show when a token is used, not that it exists," Docker wrote, so a token that was transferred but never used leaves no trace. For that reason it treated every transferred token as potentially affected, emailed the users concerned on 2 October, and switched those tokens off on 8 October.
What to check now
Docker says anyone who did not receive its 2 October email was not exposed. Even so, both sides recommend the same housekeeping. In Account settings, open Personal access tokens and revoke anything unfamiliar or unused. The researchers add one caution. Token names are chosen by whoever creates them, so a familiar-looking name proves nothing. They also suggest checking the account switcher for an organisation you do not remember joining.
For automation that belongs to a team, Docker now recommends organisation access tokens rather than a person's PAT. The company has stopped transferring tokens during conversion and will ask for consent before naming someone an organisation owner. It says it is reviewing other flows that change who owns a credential.
Why a quiet bug matters
Container registries sit near the top of many software supply chains, and an image's trustworthiness rests largely on the name it is published under. A flaw that let a stranger borrow that name for two years without anyone noticing is serious even if, as Docker's review suggests, nobody did. The lesson for platform teams is the one Docker drew itself: any feature that moves credentials between owners needs consent, notification and an audit trail.
View author profile → · Editorial policy
