The token and the secret are not the same object, and the fix date is not the email date. Docker’s advisory for CVE-2026-105445 says a personal access token could be reassigned to another user during an account-to-organization conversion, without changing the secret and without the named owner’s consent. Bill Toulas at BleepingComputer, October 13, 2026, 11:20 AM reports the same bug and adds a count Docker’s timeline, in the chunks I used, does not lead with: 304,000 pushes examined, and no evidence of exploitation. The Hacker News, also October 13, reports a CVSS 4.0 score of 9.4 on the CVE record published that day. Three pages, one CVE. The score is The Hacker News’s account of the record. I am not pasting 9.4 onto Docker’s blog timeline, because the timeline chunks I used did not include it.
We already had a Docker surface that was a YAML file, not a daemon flag. Docker Agent in Desktop 4.63 was that file. We already had a runtime that was not Docker Desktop. WSL containers went GA on a different path. We already had a CVE where the thing to check was the kernel, not the Docker version string. CVE-2026-80521 was that split. This one is Hub, not the engine on the host. A docker version that looks current does not answer it.
I am not going to write a conversion procedure. The advisory already describes the class of bug. What follows is the window, the clock, and the check. If Docker’s portal text disagrees with a secondary writeup, the advisory wins, and this piece is a map of what the October 13 stories added.
Docker Hub’s window opens in 2024. The fix is September 30, 2026
Docker’s advisory, in the chunks covering scope, says the exposure window ran from August 26, 2024, 20:33 UTC, until the fix was deployed on September 30, 2026, at approximately 19:10 UTC. That is a little over two years. BleepingComputer dates the introduction to August 26, 2024, when conversion started reassigning the personal-account PAT to the new owner, without revoking or rotating the secret, and without asking the named owner to confirm. The Hacker News calls it a two-year-old flaw in the headline. The year count and the UTC timestamps are doing the same job. I am using Docker’s timestamps for the window, and the October 13 articles for the retelling.
What an attacker could do, as Docker states it, stayed inside the token. A reassigned PAT acted as the target user at the registry level. Within the token’s scope, that meant pull, push, and/or delete images in the target’s repositories and in organizations where the target had access. Docker treated that as critical because publishing images under a legitimate name is a software supply chain risk. The vulnerability did not give access to the Docker Hub web interface. It could not be used to change the target’s password, email, or two-factor settings, or to take over the account.
BleepingComputer’s lead matches that boundary. An attacker could create an account and a PAT, convert the account into an organization, and name a target user as its owner. Hub reassigned the PAT to that owner without changing the secret or obtaining consent. Depending on scope and the target’s permissions, the attacker could pull, push, or delete images in the target’s repositories and accessible organizations. The Hacker News uses the same shape: create a token on an account they controlled, convert that account into an organization, name another user as owner, and the token then worked at the registry as that user. Registry, not the website. Not the password. Not the mailbox. Not the second factor.
A host that rotated its root password in 2025 has not, by that act, rotated a Hub PAT that moved under this bug. A CI job that still holds the old secret is the object. The secret did not change when the token’s owner field did. That is the sentence I do not want shortened to “Docker had a login bug.”
Four hours is the summary. The clock is 11:40 to about 15:10 Eastern.
Docker’s timeline is in U.S. Eastern. September 30, 11:40 AM: report received at [email protected]. About 1:30 PM: reproduced with internal test accounts. About 3:10 PM: fix deployed to production and verified against the original proof of concept. Conversion no longer transfers PATs. About 3:23 PM: documentation updated to say PATs do not transfer and must be recreated by the new owner, with organization access tokens recommended. 4:59 PM: researchers informed of the fix. Both parties agreed to coordinate disclosure.
BleepingComputer compresses the same afternoon. Docker received the report on September 30, 2026, confirmed it, and deployed a fix to production less than four hours later. From 11:40 AM to about 3:10 PM is three and a half hours. “Less than four hours” is a fair summary of that pair. It is not a second timeline. The 3:10 PM Eastern fix and Docker’s “approximately 19:10 UTC” are the same moment if you are on Eastern Daylight Time, which September 30 still is. I am not going to treat 19:10 UTC and 3:10 PM as two fixes.
The documentation line at 3:23 PM is the product change, not just the patch. PATs do not transfer. The new owner has to recreate them. Organization access tokens are the recommended object for organization automation. That recommendation is in Docker’s timeline. The Hacker News repeats the advice in plainer ops language: review tokens, revoke any you do not recognize or no longer use, and use organization access tokens, not one person’s PAT, for automation that belongs to an organization. I am willing to repeat that advice because both the advisory timeline and the October 13 writeup point at it. I am not willing to turn it into a script.
The email is October 2. Deactivation is October 8, and there is an opt-out.
Docker’s “what we did” section is the part a “patched in four hours” headline drops. On October 2, Docker emailed the limited number of users whose accounts received transferred PATs. Each email listed the in-scope tokens by description and creation date, so users could find them in Hub. Organization owners were notified separately. The timeline stamps that email at October 2, 5:30 PM Eastern. On October 8 at 3:45 PM Eastern, Docker deactivated the identified transferred PATs. Tokens that their owners asked to keep before the deadline were excluded.
Read the exclusion twice. The forced deactivation was not universal. An owner who asked to keep a transferred token before the deadline still had that token, by Docker’s own account, after October 8. BleepingComputer reports the same exception: transferred PATs were deactivated on October 8, except for those whose owners explicitly requested to retain them. If your inventory assumes “October 8 means every moved token is dead,” you have deleted the opt-out both pages printed.
Docker’s other sentence is the one that will be quoted without the opt-out. If you did not receive the email, no PAT on your account was transferred through this flow. Your account was therefore not exposed to this vulnerability, and there is no action for you to take. That sentence is about this bug’s transferred set. It is not a sentence that every PAT in your org is fine, and it is not a sentence that the opt-out set is empty. The Hacker News still says Docker advises users to review tokens and revoke ones they do not recognize. Those two instructions can sit together if you keep their scopes apart. No email means Docker does not think this conversion flow moved a token onto you. Reviewing tokens you do not recognize is hygiene The Hacker News attributes to Docker, and it is also what you would do if an email did arrive and listed descriptions you cannot match to a job.
I did not see the contents of any customer email. The advisory says the email listed tokens by description and creation date. If you got one, that list is the match key. A token named in the email and still enabled after October 8 is either an opt-out or a deactivation that did not stick. I cannot tell those apart from the public text. The account holder can.
The conversion page promised a notification. The advisory says the owner was not asked.
The Hacker News prints a contradiction I am not going to smooth. Docker’s conversion page has included the sentence “The new owner receives a notification email” since at least August 2024, according to that writeup. The same piece says the named owner was not asked to confirm the change and was not notified, according to Docker and the researchers who reported the flaw. A page that promised a notification, and a bug whose harm depends on the absence of consent, are both in that October 13 account. I did not open the conversion page as it stood in August 2024. I am using The Hacker News for the quoted sentence and for the attribution to Docker and the researchers. If the live page no longer says that, the quote is about the page as The Hacker News describes its history, not about a screenshot I took.
Docker’s own timeline does not, in the chunks I used, repeat the “notification email” sentence from the conversion page. What Docker does print is the October 2 email, which is a notice after the report, not a notice at the moment of conversion. An email on October 2, 2026, does not satisfy a promise of notice for a conversion that could have happened in 2024 or 2025. I am not saying Docker claimed it did. I am saying a reader who treats the October 2 mail as “the notification the conversion page described” has merged two clocks.
BleepingComputer’s exploitation paragraph is the other number that has to stay attached to its source. Docker says it found no evidence of exploitation after examining 304,000 pushes made with transferred tokens and analyzing high-risk public images. That is a negative finding on a defined set. It is not a proof that no private registry pull happened outside that set, and Toulas does not write it as one. “No evidence in 304,000 pushes, plus a look at high-risk public images” is the claim. A slide that says “Docker confirmed no one was hit” has upgraded a negative finding. I am leaving it as Toulas reports Docker’s finding.
What I would check, and what I would not pretend to know
If an October 2 email arrived, match the descriptions and creation dates to Hub, and treat any token the email named as in scope for this CVE even if someone later asked to keep it. The opt-out kept the secret alive on purpose. That is a decision the owner made. It is still the secret that was reassigned without a rotation.
If no email arrived, Docker’s advisory says this flow did not transfer a PAT onto that account, and no action is required for this vulnerability. I would still rather see organization automation on organization access tokens than on a person’s PAT, because that is the recommendation Docker’s 3:23 PM documentation update and The Hacker News both print. That preference is not evidence you were exposed. It is the configuration the advisory points at for the next conversion, now that conversion no longer moves the PAT.
I would not rotate a host root password and call the ticket closed. The bug was not a host login. I would not read docker version as a patch level for Hub. The fix was a production change on September 30, 2026, about 3:10 PM Eastern, to the conversion path. Engines did not ship that fix. I would not treat CVSS 9.4 as a line from the blog timeline I used. It is The Hacker News’s account of the CVE record published October 13. Critical, in Docker’s own words in the advisory chunks, is the supply-chain rating they assigned because a reassigned token could publish under a legitimate name. The word and the 9.4 can describe the same bug and still come from different pages.
The secret did not change when the owner field did. That is the whole defect. The email, the deactivation, and the opt-out are the cleanup, and they are three dates, not one.
