Docker Hub fixed an issue that transferred automation credentials to a new owner when a personal account became an organization. Attackers could use credentials they held with someone else's privileges. Development teams that used account conversion should review impact notifications and token handling records.

1. How an ownership change enabled privilege misuse

Docker Hub offers personal account conversion to an organization rather than repository transfers to another account. This preserves repository addresses so existing image download paths keep working, while designating an existing account as the organization owner.

The problem was that the converted account's personal access tokens were also reassigned to the new owner. Tokens are credentials used for automation instead of passwords. Only the ownership record changed: secrets were neither replaced nor revoked, and the new owner received no consent request or notification.

An attacker could create a token in their own account, then convert that account into an organization and designate a victim as owner. The attacker could then authenticate as the victim using the secret they already knew. It was like changing the name on someone else's access badge to the victim's name.

Docker disclosed the issue as CVE-2026-105445. Within the token's permissions, attackers could download, upload, or delete images in repositories belonging to the victim and organizations the victim could access. Docker assessed this as a supply chain risk, since images could be distributed under legitimate names. It said web interface access, password, email, or two-factor authentication changes, and account takeover were not possible.

2. Scope of the fix and impact notifications

The exposure period ran from August 26, 2024, at 20:33 UTC to approximately September 30, 2026, at 19:10 UTC. Docker deployed a production fix less than four hours after receiving the report, removing token transfers during account conversion. This blocked privilege misuse through that route, but new owners must now recreate tokens.

Docker emailed potentially affected users and relevant organization owners on October 2, 2026, at 5:30 p.m. It then disabled transferred tokens on October 8 at 3:45 p.m., except those whose owners had requested retention before the deadline. Both times were listed in the advisory in US Eastern Time.

Notifications included descriptions and creation dates of the affected tokens. Docker said users who did not receive that email, and members of organizations they manage, were not exposed to this vulnerability and need take no further action.

3. Abuse investigation findings and remaining blind spots

Docker investigated all account conversions since the issue was introduced. It cross-checked authentication logs, service usage data, and token records to find tokens used under multiple identities, and reviewed all roughly 304,000 image uploads made with transferred tokens.

It found no evidence of abuse. Image uploads went only to repositories of the converted organization or the new owner, with none recorded to unrelated users or organizations. Most conversions were legitimate cases where the same person or team owned both accounts.

High-risk public images uploaded after conversions where control of both accounts by the same person could not be confirmed underwent static analysis without execution. Docker reported no signs of malware, cryptocurrency mining, or command-and-control communications, and no evidence that its own infrastructure or services were affected.

However, logs record token use, not token existence, so transferred but unused tokens leave no trace. Rather than limiting the scope to detected activity, Docker treated all tokens transferred through conversions during the exposure period as potentially affected.

4. User checks and follow-up changes

As general security guidance, Docker recommended revoking unfamiliar or unused tokens from the personal access token page in account settings. It also recommended organization access tokens rather than personal tokens for organizational automation.

Docker outlined follow-up measures: consent before organization owner designation, notification afterward, auditable token ownership change records, and reviews of other credential ownership change flows. These measures supplement investigations based on usage traces by recording ownership changes themselves.

The core response is to block token transfers, require consent for organization owner designation, and maintain traceable records of token ownership changes.