Summary
- Docker confirmed a credential ownership weakness tracked as CVE-2026-105445.
- The company fixed the flow on 30 September, notified exposed users on 2 October, and deactivated identified tokens on 8 October.
- Docker says users who did not receive its exposure notice were outside the affected conversion population.
Docker has disclosed a vulnerability in Docker Hub account conversions that caused some personal access tokens to move between account owners without the associated secret being rotated or revoked. The company says it fixed the issue within four hours of receiving a responsible disclosure on 30 September and has notified the limited population of users whose tokens could have been affected.
The problem, tracked as CVE-2026-105445, concerned a workflow in which a personal Docker Hub account is converted into an organisation. That conversion allows the existing repository namespace to remain available, avoiding disruption to applications that download container images using the previous image reference. The account conducting the conversion identifies another user who will own the newly created organisation.
Docker explained that, from 26 August 2024, this operation could also reassign personal access tokens belonging to the converted account. The token owner changed in internal records, but the token secret remained the same. Consequently, a credential that had been issued within one account context could continue to exist with ownership linked to another user.
The company reviewed conversions going back to the date the behaviour was introduced. It says it treated every transferred token as potentially exposed rather than requiring evidence that someone had misused it. This was a precautionary assessment of the affected credentials, not a finding that all those accounts were exploited.
Users and organisation owners identified by the review were notified on 2 October. Docker subsequently deactivated the identified transferred tokens on 8 October, except those that owners had expressly asked to retain before the deadline. Its public explanation followed on 12 October.
Credential lifecycle and repository trust
A personal access token is an authentication credential that may enable automated access to services without repeatedly asking for an account password. In a developer environment, such tokens can be embedded in scripts, build jobs, and deployment pipelines. Their privileges vary, so the consequences of misuse depend on what actions each token permits.
Docker Hub is used to publish and retrieve container images. If a token with write permissions is misused, it may permit unauthorised operations involving image repositories; credentials limited to reading have a different risk profile. An issue in token ownership can thus intersect with software delivery trust, particularly when the affected account controls images consumed by production systems.
The company says the immediate fix removed personal access token transfer from account conversion. It is also introducing explicit consent before someone becomes an organisation owner, notifications of ownership changes, and auditable records of token reassignment. The additional measures address the governance problem that made the original behaviour difficult for a user to observe.
Docker told customers who did not receive an exposure email that they were not part of the affected conversion population and did not need to take specific action relating to this vulnerability. It also recommends routine review of account tokens and use of organisation access tokens for automation that belongs to an organisation rather than an individual developer.
Docker’s findings do not describe an indiscriminate compromise of Docker Hub. There is no public evidence in the disclosure that the platform’s image repositories were broadly accessed, that attackers stole all personal access tokens, or that any specific production image was tampered with.
The weakness arose because credential secrets and ownership records followed different lifecycles. An account conversion changed the recorded owner without forcing the credential to be replaced. That is different from the ordinary case of accidentally posting a token in a public repository, but it can create uncertainty over who should be able to exercise existing privileges. Docker’s proposed consent and audit measures are intended to make such ownership changes more explicit and reviewable.
Docker credited researchers Peter Molnar and Krisztian Hozak of mptrdev.com with reporting the flaw. Docker’s incident timeline documents both a technical correction and the later notification and credential-deactivation steps, giving affected users a record against which to reconcile their own account activity.
