News Vulnerabilities & Zero-Days
Docker Hub flaw let users act as others in the registry for two years
Docker fixed CVE-2026-105445, a critical Docker Hub flaw that let a user push, pull or delete images as another user by abusing account-to-organization conversion. Docker says it found no evidence of exploitation and has deactivated the affected tokens.
Key takeaways
- CVE-2026-105445 let a Docker Hub user push, pull or delete images as another user.
- The flaw existed from 26 August 2024 until it was fixed on 30 September 2026.
- It worked by abusing account-to-organization conversion, which transferred personal access tokens.
- Docker says it found no evidence of exploitation after reviewing about 304,000 pushes.
- Use organization access tokens for automation and revoke tokens you do not recognise.
Docker disclosed CVE-2026-105445 on 12 October 2026, a flaw in Docker Hub that let one user authenticate to the registry as another. The flaw existed from 26 August 2024 until Docker fixed it on 30 September 2026. Docker rates it critical because a misused token could publish images under a legitimate name, a software supply chain risk.
How did the flaw work? #
When a personal Docker Hub account was converted into an organization, its personal access tokens were reassigned to whichever user the converter named as owner. Docker changed the token's owner record without rotating or revoking the secret, and the named owner was not asked or told.
That meant an attacker could create an account, generate a token, convert the account and name a target user as owner. The attacker kept the token secret, which then authenticated to the registry as the target.
The access was limited to registry actions, pull, push and delete, within the token's scope. Docker says it did not reach the web interface, passwords, email or two-factor settings, and did not allow account takeover.
Was it exploited? #
Docker says it found no evidence of exploitation. It reviewed every conversion since 26 August 2024 and about 304,000 pushes made with transferred tokens. Every push went to the converted organization's own repositories or the named owner's. Static analysis of the highest-risk public images found no malware or tampering.
Docker notes that logs cannot prove a token was never used, so it treated every transferred token as potentially affected.
What has Docker done? #
| Date (2026) | Action |
|---|---|
| 30 September | Report received; fix deployed the same afternoon so conversions no longer transfer tokens |
| 2 October | Affected users and organization owners emailed |
| 8 October | Transferred tokens force-deactivated, except those owners asked to keep |
| 12 October | Advisory published |
Docker now requires consent before someone is named an organization owner, notifies them, and keeps an auditable history of token ownership changes. It credits Peter Molnar and Krisztian Hozak of mptrdev.com, who reported the issue.
What should Docker Hub users do? #
- Review your personal access tokens under Account settings, then Personal access tokens, and revoke any you do not recognise or no longer use.
- Use organization access tokens, not an individual's personal token, for organization automation such as CI pipelines.
- If you did not receive Docker's email on 2 October, Docker says you were not exposed.
Sources
- Docker Hub security advisory for CVE-2026-105445, Docker
- Report on the two-year-old Docker Hub flaw, The Hacker News
Questions this raises
- Do I need to update anything?
- No. Docker fixed the flaw on Docker Hub itself on 30 September 2026. Review your personal access tokens and revoke any you do not recognise.
- Could someone have taken over my account?
- No. Docker says the flaw was limited to registry actions and did not allow changes to passwords, email or two-factor settings.
- How do I know if I was affected?
- Docker emailed affected users and organization owners on 2 October 2026. If you did not receive that email, Docker says you were not exposed.
Supply Chain SecurityContainer SecurityVulnerabilityCI/CD SecurityDocker