ProductNot yet confirmed elsewhere1 publisher2 min readPublished
Docker Hub account conversions carried personal access tokens to a new owner for 765 days
Docker fixed critical Docker Hub flaw CVE-2026-105445 under four hours after a report, ending a 765-day exposure window. Docker says it found no evidence of exploitation; the open check for teams is whether anyone of theirs was named owner in a conversion.
The Product Desk

Timeline. August 26, 2024: conversions start re-assigning tokens to the new owner. September 30, 2026: report confirmed, fix deployed in under four hours. October 2: Docker emails exposed users. October 8: transferred tokens force-deactivated, except opt-outs.
| Date | Event | Claim |
|---|---|---|
| August 26, 2024 | Conversions begin re-assigning tokens to the new owner | 5 |
| September 30, 2026 | Report confirmed; fix deployed in under four hours | 1 |
| October 2, 2026 | Email sent to the limited number of exposed users | 2 |
| October 8, 2026 | Transferred tokens force-deactivated, except opt-outs | 13 |
What happened
- From August 26, 2024, converting a Docker Hub account to an organization re-assigned its personal access tokens to the named owner by editing the owner record, without rotating or revoking the secret.
- In the attack Docker describes, an attacker converts an account it created, names a target as owner, and keeps the token secret while the token authenticates as the target at the registry.
- Docker listed every conversion since August 26, 2024 and examined about 304,000 pushes made with transferred tokens against registry logs, usage data and token records.
- On October 8, Docker force-deactivated every personal access token transferred through conversion, except where the account holder opted out.
Why it matters
- exposure The person at risk was the named owner, who was neither asked nor told at conversion, so a team has no record of its own to search and has to rely on the October 2 notice.
- cost Teams that converted their own accounts in good faith also lost transferred tokens on October 8 unless they opted out, so any pipeline that used one needs a new credential.
- decision Conversion now needs a credential rebuild in the runbook, because Docker's documentation says tokens no longer transfer and the new owner must recreate them.
An admin searching a shared inbox for the subject line "Docker Hub Vulnerability Identified & Resolved" either finds the message or does not. Docker says it sent that email at 5:30 PM Eastern on October 2 to the limited number of users it judged exposed [2]. Its advice for everyone else is short: if no email arrived, neither you nor the members of the organizations you administer were exposed, and there is nothing to do [3].
The check is narrower than whether a team ever converted an account. Conversion is routine, because Hub has no way to move a repository between accounts and conversion is how alice/app becomes an organization-owned alice/app without breaking pulls [4]. In the attack Docker describes, the converter is the attacker [7]. In our reading, the person to look for is whoever on staff was named owner on an account they did not create. A team that converted its own account and named its own admin moved its own tokens.
Docker said an attacker could potentially pull, push or delete images, both in the target's own repositories and in any organization the target could access. With that access an attacker could ship images under the genuine name, so Docker treated the flaw as a software supply chain risk and rated it critical [8]. It did not open the Hub web interface, and it could not change the target's password, email address or two-factor settings [9].
The window ran from 20:33 UTC on August 26, 2024 [10] to a fix at about 3:10 PM Eastern on September 30, 2026 [11]. That is 730 days to August 26, 2026 plus 35 more, or 765 days [16]. The report reached Docker at 11:40 AM on the day of the fix, a gap of 3 hours 30 minutes [11][17].
Every one of the roughly 304,000 pushes Docker examined landed in the converted organization's own repositories or the new owner's own [15]. That is Docker's finding from Docker's logs, and the count it gives is of pushes.
We'd sort each account on two facts: whether the October 2 email reached a mailbox someone reads, and whether the holder opted out of the October 8 deactivation.
- No email: Docker says no action. Confirm the address on the Hub account is monitored, since the email is the only signal Docker describes. - Email, no opt-out: the transferred tokens were deactivated on October 8 [13]. Find the pipelines that used them and issue replacements. - Email, opted out: those tokens were left active on October 8 [13]. Revoke them, or give each one an owner and a rotation date.
What to watch
- Whether the researchers' technical write-up at ghostpat.com describes anything Docker's audit of pushes did not cover.
- Whether Docker publishes how many accounts received the October 2 email, since the advisory says only a limited number.
- Whether Docker later deactivates the tokens whose holders opted out on October 8.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence55
- Adoption
- Insufficient
- Hype gap0
- Incentives55
- Confidence60
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
Docker confirmed the September 30, 2026 report and deployed a fix to production the same afternoon, less than four hours after receiving it.
- [2]
On October 2 at 5:30PM EST, Docker sent an email with the subject line "Docker Hub Vulnerability Identified & Resolved" to the limited number of users exposed to the vulnerability.
- [3]
Docker says that if you did not receive the email, you and any members of the organizations you administer were not exposed and there are no actions to take.
- [4]
Docker Hub has no way to move a repository from one account to another; converting a personal account into an organization is how alice/app becomes an organization-owned alice/app without breaking every Docker pull that references it.
- [5]
Beginning August 26, 2024, account conversion also re-assigned the converted account's personal access tokens to the new owner by changing the token's owner record, without rotating or revoking the token secret.
- [6]
The named owner in a conversion was not asked to confirm and was not notified.
- [7]
In the attack Docker describes, an attacker creates an account and generates a PAT, converts the account to an organization naming a target user as owner, and the PAT is re-assigned to the target while the attacker still holds the secret; the token then authenticates to the registry as the target user.
- [8]
Within the scope of the token, an attacker could potentially pull, push, and/or delete images in the target's repositories and in organizations where the target had access; because that includes publishing images under a legitimate name, Docker treated it as a software supply chain risk and rated it critical.
- [9]
The vulnerability did not give access to the Docker Hub web interface and could not be used to change the target's password, email address, or two-factor settings, or to take over the account.
- [10]
The exposure window ran from August 26, 2024, 20:33 UTC, until the fix was deployed on September 30, 2026.
- [11]
In Docker's timeline (U.S. Eastern), the report was received at security@docker.com at 11:40 AM on September 30, and the fix was deployed to production at about 3:10 PM.
- [12]
Docker's documentation was updated on September 30 to state that PATs do not transfer on conversion and must be recreated by the new owner, with organization access tokens recommended.
- [13]
On October 8 at 3:45 PM, Docker force-deactivated all PATs transferred through conversion, except where the account holder opted out.
- [14]
Docker enumerated every account conversion since August 26, 2024, correlated them with registry authentication logs, Docker Hub usage data and IAM token records, looked for any token used under more than one identity, and examined every push made with a transferred token, about 304,000 in all.
- [15]
Every push made with a transferred token landed either in the converted organization's own repositories or in the new owner's own repositories.
- [17]
The fix was deployed about 3 hours 30 minutes after the report was received.
- [18]
Docker found no evidence that the vulnerability was exploited.
ReportedContestedSource: Docker security advisory2 sources— create a free account to open themView cited source
Sources
1 independent publisher whose own reporting we read for this story.
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.
Topics
- Vulnerability DisclosureFollow
- Software Supply Chain SecurityFollow
- Container registry securityFollow