Docker Hub CVE-2026-105445 let tokens impersonate repo owners
A Docker Hub flaw (CVE-2026-105445) transferred personal access tokens during account-to-org conversions, letting an attacker push or delete images as another user. Fixed; no abuse found.
Docker fixed a flaw in Docker Hub that transferred a personal access token (PAT) to a new owner when an account was converted into an organization — without changing the token's secret. CVE-2026-105445, which Docker rates critical, let an attacker who controlled a convertible account mint a token, convert the account, and name a victim as owner; the token then authenticated at the registry as that victim. Docker found no evidence of exploitation, but if you have a Docker Hub account, this is a token-hygiene checklist worth running today.
The primary source is Docker's advisory, Docker Hub security advisory: CVE-2026-105445. The researchers who reported it published a technical writeup, which they named GhostPat, at ghostpat.com.
How it worked
Docker Hub's account-to-organization conversion reassigned the account's personal access tokens to the designated organization owner, and the token secrets stayed the same. An attacker could:
- Create a PAT on an account they control.
- Convert that account to an organization.
- Name any other user as owner.
The still-valid token then worked at the registry as that user. Within the token's permission scope, the attacker could pull, push, or delete images in the victim's repositories and in organizations the victim could reach — the raw material of a supply-chain tampering attack. The access was limited to the registry: it did not reach the web interface, passwords, email, or 2FA, and it did not allow full account takeover.
Timeline and exposure
- Introduced: August 26, 2024, 20:33 UTC.
- Reported: September 30, 2026, by Peter Molnar and Krisztian Hozak of mptrdev.com.
- Fixed: September 30, 2026 — Docker says it deployed the fix less than four hours after receiving the report.
- Tokens deactivated: October 8, except where an owner opted out before the deadline.
Exploitation status
No evidence of abuse, per Docker. It enumerated every account conversion since August 26, 2024 and examined every push made with a transferred token — about 304,000 in all — then statically analyzed the highest-risk public images without executing them, finding no malware, cryptominers, C2, credential harvesting, persistence, or tampering. Docker notes logs cannot show unused transferred tokens, so it treated every transferred PAT as potentially affected. It found no sign its own infrastructure was touched.
Action checklist
- Review your PATs. In Docker Hub, go to Account settings → Personal access tokens and revoke any you don't recognize or no longer use.
- Switch org automation to organization access tokens rather than a person's PAT, so credential ownership doesn't ride on individual accounts.
- If you got Docker's notification email, a PAT on your account was transferred — treat it as burned and rotate anything that token could push to.
- Audit recently pushed image tags in repositories you own for versions you didn't publish, as a belt-and-suspenders check despite Docker's clean review.
Context
This is the registry-side cousin of the npm supply-chain incidents we keep covering — from the Mastra/easy-day.js takeover to GhostAction's return to GitHub Actions. The common thread is credential ownership drifting through an automated workflow: a token that should have been invalidated on a trust-boundary change instead carried its privileges across it. Docker's four-hour fix and 304,000-push review are the model response; the lesson for everyone else is that any feature which transfers a credential needs to rotate the secret, not just the owner.