Docker Hub Access Token Vulnerability: A Two-Year Silent Transfer

For more than two years, converting a Docker Hub account into an organization quietly reassigned that account’s personal access tokens to whoever was named as the new owner, without rotating the secret or telling the owner. Docker says it found no evidence of exploitation across about 304,000 pushes. For platform teams, the more useful lesson is in Docker’s own caveat: a token that was never used leaves no trace.

What Happened

Docker’s security advisory describes CVE-2026-105445, reported on September 30 by researchers Peter Molnar and Krisztian Hozak, whose technical write-up is public. Docker Hub has no way to move a repository between accounts, so users convert a personal account into an organization instead, naming an existing account as owner. Beginning August 26, 2024, that conversion also moved the account’s PATs to the new owner by changing the token’s owner record.

That made an attack possible. An attacker could create an account, generate a PAT, convert the account to an organization naming a target user as owner, and keep the token secret. The token would then authenticate to the registry as the target, able to pull, push, or delete images in the target’s repositories and in organizations the target could access. Docker rated it critical as a software supply chain risk, because it allowed publishing images under a legitimate name. It did not grant web interface access or allow changing passwords, email, or two-factor settings.

Docker deployed a fix the same afternoon, less than four hours after the report. Its timeline shows exposed users and organization owners emailed on October 2, and transferred PATs force-deactivated on October 8, except where owners opted out.

Why It Matters

Docker reviewed every conversion back to August 2024 and found that every push made with a transferred token landed in the converted organization’s repositories or the new owner’s own. It statically analyzed the highest-risk public images and found no malware, cryptominers, or tampering.

But Docker is candid about the limit: registry logs show when a token is used, not that it exists. So it treated every PAT that moved through conversion as potentially affected, whether or not it was seen in use. That is the right call, and it is a reminder that detection-based assurance has a blind spot for dormant credentials.

The root cause is a pattern, not a one-off bug: credential ownership changed without consent, notification, or rotation. Docker’s fixes target exactly that. It now requires consent before someone is named an organization owner, records an auditable history of every token ownership change, and is reviewing other flows that change credential ownership.

What This Means for Platform Teams

The flaw involved personal access tokens. Docker’s recommendation is to use organization access tokens for automation that belongs to an organization, rather than a person’s PAT. That matches a broader move away from long-lived personal secrets in pipelines, as with Datadog’s secretless Azure authentication.

Source: Docker Blog

Content created with AI assistance and reviewed for accuracy.