Docker Hub flaw exposed transferred access tokens
Docker says a critical Docker Hub flaw could let attackers reuse personal access tokens to access another user’s repositories and tamper with container images.
Docker says it has fixed a critical Docker Hub vulnerability that could let attackers use a personal access token as another user and pull, push or delete container images within that token’s scope. 1
How the Docker Hub flaw worked
The issue affected conversions from a personal Docker Hub account into an organisation. From 26 August 2024, the conversion process could reassign the account’s personal access tokens to a newly named organisation owner without rotating the secret or asking that owner to consent. An attacker who still held the token could then authenticate to the registry as the target user. 1
Depending on the token’s permissions, that could allow images to be pulled, pushed or deleted in repositories belonging to the target user and organisations they could access. Docker treated the issue as a critical software supply-chain risk and assigned it CVE-2026-105445. 12
What Docker did
Docker says it received the vulnerability report on 30 September 2026, reproduced it and deployed a fix less than four hours later. The platform no longer transfers personal access tokens during account conversion and now requires consent before naming someone as an organisation owner. 1
Docker reviewed roughly 304,000 pushes made with transferred tokens and says it found no evidence that the flaw was exploited. It nevertheless treated every transferred token in the exposure window as potentially affected, deactivating those tokens on 8 October except where owners had explicitly asked to keep them. 1
Users who received Docker’s 2 October notification should review the listed tokens and revoke anything they do not recognise. Docker recommends organisation access tokens for automation that belongs to an organisation. 1
Our opinion
The reassuring part is Docker’s claim that it found no evidence of exploitation. The less reassuring part is how long a credential-ownership bug could leave a secret valid under the wrong identity. “No evidence” is not the same as “no possible exposure”, which is why the token deactivation and notification process matters.
The practical lesson is simple: treat personal access tokens as credentials, not as harmless account metadata. If an organisation conversion or ownership change touches one, rotate it rather than assuming the platform has handled the handover safely.