Skip to content

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

How we use AISend a correction

Illustration accompanying Docker Hub account conversions carried personal access tokens to a new owner for 765 days
Generated illustration
Docker fixed the token flaw the day it was reported Dates in Docker's security advisory on Docker Hub account conversions and personal access tokens

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.

Docker fixed the token flaw the day it was reported
DateEventClaim
August 26, 2024Conversions begin re-assigning tokens to the new owner5
September 30, 2026Report confirmed; fix deployed in under four hours1
October 2, 2026Email sent to the limited number of exposed users2
October 8, 2026Transferred tokens force-deactivated, except opt-outs13

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
Why these scores

Claim ledger

Ranked by verification strength, evidence, and original report placement.

  1. [1]

    Docker confirmed the September 30, 2026 report and deployed a fix to production the same afternoon, less than four hours after receiving it.

    ReportedSupportedSource: Docker security advisoryView cited source
  2. [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.

    ReportedSupportedSource: Docker security advisoryView cited source
  3. [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.

    ReportedSupportedSource: Docker security advisoryView cited source

Sources

1 independent publisher whose own reporting we read for this story.

  1. docker.com

    1 article · October 12, 2026

    Docker Hub security advisory: personal access tokens transferred during account-to-organization conversions

Share your take

Let Clarity write the post for you.

Signed-in readers get a short post drafted on this story in the register they choose — narrative, analytical, or a direct position — editable to the last word before it goes anywhere. The share buttons at the top of this story work without an account.

Topics and entities

Follow any of these and your For You feed starts watching them — no settings page required.

Entities

Loading related stories