Docker Hub Account Conversion Handed Access Tokens to Another User for 25 Months, Rated CVSS 9.4

An authenticated Docker Hub user could create a personal access token, convert their account into an organization, name another user as owner, and the token then worked at the registry as that user, pushing, pulling or deleting images within the token's scopes. Docker fixed it on Docker Hub itself on Sept. 30, 2026, so there is no update to install, but anyone who received an Oct. 2 email should review their tokens.

The CVE record, published Oct. 13, rates CVE-2026-105445 at CVSS 4.0 9.4 (network, low complexity, low privileges, no user interaction). It describes an incorrect privilege assignment, CWE-266, in the account-to-organization conversion, and lists affected builds from 2024-08-26T20:33:00Z to 2026-09-30T19:10:00Z.

What an attacker needed and what they got

The score overstates the reach in one direction and understates it in another. Access was limited to the registry: Docker says the flaw did not grant web access and could not change passwords, email addresses or two-factor settings. But the token's secret was never rotated, and the named owner was not asked to confirm or notified, so the attacker held a credential that already worked and could reach organization repositories the user could access.

The Hacker News reports that Docker's conversion page had said since at least August 2024 that "The new owner receives a notification email." The researchers, Peter Molnar and Krisztian Hozak of mptrdev.com, reproduced the flaw twice on test accounts whose owners consented.

The timeline in Eastern time

When	Event
Aug. 26, 2024	Flaw window opens
Sept. 30, 2026, 11:40 AM	Report reaches [email protected]
Sept. 30, about 3:10 PM	Fix deployed and checked against the proof of concept
Oct. 2, 5:30 PM	Exposed users and organization owners emailed
Oct. 8, 3:45 PM	Transferred tokens deactivated, except where owners opted out
Oct. 12 and 13	Advisory and CVE published

Docker's advisory, written by Mark Lechner (listed as CISO, and in the body text as chief security officer), puts the fix about three and a half hours after the report. Documentation was updated about 13 minutes later to say tokens do not transfer.

What Docker checked, and what it cannot prove

Docker examined "every push made with a transferred token, about 304,000 in all", and wrote: "We found no evidence that the vulnerability was exploited." The Hacker News adds that all those pushes went to repositories of the converted organization or its named owner, in most cases controlled by one person or team. Where Docker could not confirm that, it analysed the highest-risk public images without running them and found no malware or tampering.

Two limits matter. The 304,000 figure counts pushes reviewed, not accounts affected, and the advisory calls the notified group only a "limited number" of users. And registry logs record use, not existence, so Docker says it treated every token transferred during the window as possibly affected. The advisory, as read here, reports results for pushes only; it does not state findings for pulls or deletions, including pulls from private repositories.

What to do now

Docker says anyone who did not receive the Oct. 2 email was not exposed and has nothing to do. Everyone else should review tokens, revoke ones they do not recognise or use, and move organization automation to organization access tokens. Docker now requires consent before a user is named owner in a conversion, notifies that user, and records every change in token ownership; it says it is reviewing other features that change credential ownership.

Compare the Ledger implant case for what supply chain tampering looks like when logs cannot settle the question, and the Bricksforge plugin flaw for a flaw where exploitation attempts were counted by IP address.

The next thing to watch is whether Docker publishes the results of its review of other credential-ownership features.