Docker Hub's flaw let a token act as another user for 765 days; Docker says the fix took under four hours

765 days in place, 3 hours 30 minutes to fix, 8 days to switch the tokens off

For 765 days (derived: 26 August 2024 to 30 September 2026, counted by calendar), Docker Hub's account conversion did something the user named as the new owner was never asked about. It re-assigned the converted account's personal access tokens to that user and left each token's secret unchanged. Docker says it confirmed and fixed the flaw, CVE-2026-105445, "less than four hours" after a report on 30 September 2026. Its own timeline gives 3 hours 30 minutes, from 11:40 AM to about 3:10 PM US Eastern (derived).

Neither number measures what a reader needs. The 765 days is how long the flawed behaviour was in place, not how long anyone was exposed, and not how many were. The four hours is the speed of one fix. On Docker's own timeline the tokens the flaw had already moved were switched off on 8 October, 8 days after the fix (derived), so for a token moved on the first day the span from change to switch-off is 773 calendar days (derived, and an inference explained below). And "no evidence of exploitation" is Docker's finding from its own check of about 304,000 pushes made with transferred tokens and its analysis of high-risk public images. Docker itself says a transferred token that was never used leaves no trace in its logs.

Two figures this briefing relies on were checked against Docker's bulletin before use. Docker does not say "four hours": it says "less than four hours", and its timeline gives 3 hours 30 minutes (derived). Docker does not say "765 days" either. It gives the start, 26 August 2024 at 20:33 UTC, and the end, 30 September 2026 at about 19:10 UTC, which count 765 calendar days and 764 days 22 hours 37 minutes elapsed (both derived). Both figures hold, with those labels.

This briefing read Docker's security bulletin in full, the CVE record and the NVD entry through their public data services, the reporters' own write-up (not linked: it carries step-level detail) and Docker's documentation, from 19:53 BST on Tuesday 13 October 2026. BleepingComputer's report of the same day was read once in a browser tab as the pointer to the bulletin: every figure in it agrees with Docker's. Everything Docker says about its own checks is Docker's account of its own work. No independent test was run, and none is described here.

What the flaw was, described as a class

Docker Hub lets a user convert a personal account into an organisation. Docker's bulletin explains why people do it: Hub has no way to move a repository from one account to another, so conversion is how a personal namespace becomes an organisation-owned one without breaking every pull that names it. Docker's documentation says the Docker ID becomes the organisation and that the user must name a different account as its owner, who then has full administrative access. Docker says that from 26 August 2024 conversion also re-assigned the converted account's personal access tokens (PATs) to that named owner, "without rotating or revoking the token secret", and that "the named owner was not asked to confirm and was not notified".

The class is a bearer credential whose identity is a field that can be moved. A PAT is a secret that authenticates to the registry in place of a password. Whoever holds the secret acts as the user the token is attached to. The bug moved the attachment and left the secret with whoever had created it. Docker's words: "Within the scope of the token, a re-assigned PAT acted as the target user at the registry level". That meant pulling, pushing or deleting images in the target's repositories and in organisations the target could reach. Docker rated it critical because it includes publishing images under a legitimate name, which it calls a software supply chain risk.

Docker states three limits. The flaw did not give access to the Docker Hub web interface, could not change the target's password, email address or two-factor settings, and could not take over the account. So the reach was the registry: the surface a downstream user of an image trusts. The reporters' own page adds, from tests they say used consenting test accounts, that the token also inherited the target's organisation memberships and could read the target's private repositories, and that no notice reached the receiving user. It flags a worst case for Docker's Official Images as "flagged, not confirmed". Docker's bulletin does not mention Official Images. This briefing gives no steps, commands or token formats: the class and the controls are what a defender needs.

The CVE record for CVE-2026-105445 as read from the CVE Services data and the NVD data service on 13 October 2026. Docker is the CNA, so the score is Docker's.

Field	What the record says
Assigner (CNA)	Docker. The record's discovery source is "EXTERNAL", and it credits two reporters at mptrdev.com (names not repeated here).
Title and weakness	"Docker Hub account conversion could reassign an active personal access token to another user". CWE-266, Incorrect Privilege Assignment.
Score	CVSS v4.0 base 9.4, critical, assigned by Docker. Network, low complexity, no attack requirements, low privileges, no user interaction, high impact on confidentiality, integrity and availability, for the vulnerable and the subsequent system. Not recomputed here.
Affected	"Docker Hub", from 2024-08-26T20:33:00Z to before 2026-09-30T19:10:00Z. A date range, because there is nothing for a customer to install. Tagged "exclusively-hosted-service".
Dates	Reserved 5 October 2026. Published 13 October 2026 at 17:35 UTC. NVD received it at 18:17 UTC and still showed the status "Received" with no NVD assessment at 19:14 UTC (20:14 BST).
Known exploited	Not in CISA's Known Exploited Vulnerabilities catalogue as released at 19:10 UTC on 13 October 2026 (read at 20:14 BST). That can change within the hour.

Three clocks: years for the flaw, hours for the fix, days for the switch-off

Docker's timeline is in US Eastern time. Its text says "5:30PM EST" in one place, but October is daylight time, and the CVE record's end of the window, 19:10 UTC, equals 3:10 PM Eastern daylight time, which is when Docker's timeline puts the fix (derived). So daylight time is used throughout. Intervals are derived from those stated times, and the stated "about" times are approximate.

Docker's dated record with intervals worked through. Times are US Eastern unless marked UTC, from Docker's bulletin (12 October 2026) and the CVE record. Intervals marked derived are this briefing's arithmetic.

What happened	When	Interval (derived)
Conversion starts re-assigning tokens	26 Aug 2024, 20:33 UTC	Start of the window
Report received by Docker	30 Sep 2026, 11:40 AM	765 calendar days after the start
Docker reproduces it with internal test accounts	30 Sep, about 1:30 PM	1 h 50 min after the report
Fix deployed and checked against the original proof of concept. Conversion no longer transfers tokens	30 Sep, about 3:10 PM (19:10 UTC)	3 h 30 min after the report. Docker: "less than four hours"
Documentation updated. Researchers told of the fix	30 Sep, about 3:23 PM and 4:59 PM	3 h 43 min and 5 h 19 min after the report
Emails to exposed users and to their organisation owners	2 Oct, 5:30 PM	2 days 2 h 20 min after the fix (2 calendar days)
Transferred tokens deactivated, except where owners asked to keep them	8 Oct, 3:45 PM	8 days after the fix, 6 calendar days after the emails
Docker publishes its bulletin	12 Oct (page data: 09:00 Pacific)	12 days after the report
CVE record published. BleepingComputer reports	13 Oct (17:35 UTC for the record)	13 days after the report

Three readings follow from the table. First, the code path and the tokens are different things. The fix on 30 September stopped new transfers. Tokens already moved stayed tied to their new owners until the switch-off on 8 October, and Docker's own description of the flaw says the creator "still holds the secret and the PAT remains active". That the moved tokens stayed usable until 8 October is an inference from Docker's timeline, not a sentence Docker writes, and Docker does not say whether the check of pushes ran to the fix or to the switch-off. Second, Docker moved fast on the people: it says it reviewed "every account conversion back to the date the flaw was introduced" and emailed the affected two days after the fix. Third, the opt-out is a loose end. Tokens whose owners asked to keep them were excluded from the deactivation, and the deadline for asking is not stated.

Stated and not stated: the record, line by line

The table sets what Docker states, in its bulletin or the CVE record, against what neither states. The reporters' page is marked where it is the only source. "Not stated" means not found in the sources read in full. It does not mean the information does not exist.

What Docker's bulletin (12 October 2026), the CVE record and the reporters' own page state, and what they do not. Read on 13 October 2026.

The question	Stated	Not stated
Was it exploited?	Docker: "We found no evidence that the vulnerability was exploited." The reporters say their tests used consenting test accounts.	That it was not exploited. What a pull or a delete looks like in the logs it checked. How many conversions the review covered.
How many accounts, tokens, conversions?	"The limited number of users exposed". In "the large majority of cases" the converted account and the named owner were one person or team.	Any count of conversions, tokens, accounts or organisation owners. The size of the minority that were not one person or team.
What was examined?	Every conversion since 26 Aug 2024 against authentication logs, usage data and token records. Any token used under more than one identity. Every push made with a transferred token, about 304,000. Highest-risk public images, analysed statically.	The period the 304,000 pushes cover. How many images were analysed. How Docker established that one person controlled both accounts.
Pulls and deletes?	Docker examined "every push". It also looked for tokens used under more than one identity.	Any finding for pulls, deletes or repository listings.
Private repositories?	The image analysis covered public images. The reporters say a token could read the target's private repositories in their tests.	Whether Docker looked for private reads, and what it found.
Tokens never used?	Docker: "registry logs show when a token is used, not that it exists". It therefore treated every PAT that moved through conversion in the window as potentially affected.	How many transferred tokens were never used.
Who was told?	An email on 2 October at 5:30 PM Eastern, subject "Docker Hub Vulnerability Identified & Resolved", listing the tokens by description and creation date, and a separate notice to organisation owners. No email means not exposed.	How many emails went out. Whether each address was current. Whether a recipient could ask for the list again.
Should recipients rotate?	Docker: review personal access tokens and revoke those you do not recognise or no longer use. Use organisation access tokens for organisation automation. Transferred tokens were deactivated on 8 Oct.	Whether a token kept by opt-out should be rotated. The opt-out deadline. Any advice to review images pushed since 26 Aug 2024.
Who reported it?	Two researchers at mptrdev.com, thanked by Docker and credited in the CVE record, through Docker's vulnerability disclosure programme. Their page dates first tests to 28 and 29 September.	Any reward. Whether anyone else found it earlier.
Other flows and records?	Docker is "reviewing other flows that change credential ownership for the same pattern" and is now recording an auditable history of token ownership changes.	The result of the review. Whether customers can read the history. Whether such a history existed before (its wording suggests not, an inference).
Official Images?	The reporters flag a worst case for them, "not confirmed". Docker found no evidence its own infrastructure or services were affected.	Whether any Official Images publishing path was reachable.

What a check of about 304,000 pushes can and cannot show

Docker's evidence of no exploitation has two parts. It says every push made with a transferred token landed in the converted organisation's own repositories or in the new owner's own repositories, and none in an unrelated user's or organisation's account. And it statically analysed, without executing them, the highest-risk public images, defined as images pushed after a conversion where it "could not establish that the same person controlled both accounts". It reports no malware, cryptominers, command-and-control activity, credential harvesting, persistence or tampering. Read carefully, the first part has a catch. The attack's pushes would land in the target's own repositories, because the token acts as the target, and "the new owner's own repositories" is where Docker says every push landed. So the landing place alone cannot clear a push (inference from the two sentences). What separates the cases is whether Docker could establish that one person or team controlled both accounts, and the image analysis of the cases it could not.

What Docker's check of transferred-token pushes can show and cannot show, from its bulletin. The right-hand column is this briefing's reading, marked where it is inference.

The part of the check	What it can show	What it cannot show
All pushes by transferred tokens, about 304,000	That none landed in an unrelated user's or organisation's account.	That a push into the new owner's own repositories was the owner's (inference: it is also where an impostor's push would land).
Same person or team on both accounts	That in the large majority of conversions the feature was used as intended.	How that was established, or how many conversions fell outside it. No count is stated.
Static analysis of public images pushed after an unestablished conversion	That the images Docker analysed held none of the six things it lists.	Private images, images Docker judged same-owner, behaviour that appears only when an image runs, or how many images were analysed.
Registry logs	When a token was used.	That a token exists. A token never used leaves no trace (Docker's own words).
Pulls, deletes, listings	Nothing is stated.	Whether a private image was read or a tag was deleted. A pull changes nothing in the image.
Period covered	Nothing is stated.	Whether the pushes run to the fix on 30 September or to the switch-off on 8 October.

No rate is computed here. The 304,000 has no stated denominator: not tokens, not accounts, not conversions. A figure per token or per conversion would need a count Docker has not given, and any such number would be invented.

Four friendly names, and what each one proves

Four labels in this story sound like controls or descriptions. Each does a job the record does not support.

Four labels in the Docker Hub story, what each suggests, and what the record shows. From Docker's bulletin, its documentation and the CVE record.

The label	What it suggests	What the record shows
"Personal access token"	A credential that belongs to one person.	A bearer secret with an identity attached. Docker's page says a token authenticates in place of a password, and that a PAT is required for command-line sign-in when two-factor authentication is on or single sign-on is enforced. At the registry, the token stands in for the whole sign-in. Here the identity moved and the secret did not.
"Convert to an organisation"	A settings change.	A move of identity. The Docker ID becomes the organisation, the named owner gets full administrative control, the action cannot be undone, and for 765 days it carried the account's tokens to the owner.
"No evidence of exploitation"	It did not happen.	A statement about what was examined: pushes by transferred tokens, and the highest-risk public images. Docker states its own limit: a token that was never used leaves no trace.
"Fixed in under four hours"	The exposure lasted four hours.	The speed of one fix. The behaviour stood for 765 days, and tokens already moved were switched off 8 days after the fix (derived, from Docker's timeline).

A family resemblance to the npm Trusted Publishing flaw

This site's briefing on npm Trusted Publishing described a registry that, until a first publish, compared a repository's name and not the permanent numeric ID the build platform's own token carried. The Docker Hub flaw is a different mechanism with the same shape. In both, a registry bound an identity to something that can change hands, a name in one case and a token's owner record in the other, and in neither did the registry require proof from the receiving side at the moment of change. The differences matter as much. In npm's case a name was freed and re-registered. In Docker's case a feature working as built moved a live credential.

Two registry identity-binding flaws, each as its own sources state it. Sources: Bloom Security, GitHub and npm for the first (as read in this site's earlier briefing, 13 October 2026); Docker for the second.

Point of comparison	npm Trusted Publishing	Docker Hub tokens
What followed the change of hands	A publishing trust bound to a repository name.	A live token's owner record.
Proof that was missing	The numeric repository ID, stored only after a first successful publish (Bloom and npm's documentation).	Consent of the named owner, and rotation of the secret (Docker).
The fix, as stated	From 2 Oct 2026 an unvalidated configuration expires after 48 hours (GitHub).	30 Sep 2026: conversion no longer transfers tokens. Consent now required. Token ownership changes now recorded (Docker).
On exploitation	No source read reports a real hijack. A Bloom researcher said it is unknown whether anyone exploited it. GitHub's statement, as reported, does not address exploitation.	Docker: no evidence of exploitation in the pushes and public images it examined. It says unused tokens leave no trace.
Counts	Bloom's own count of more than 1,500 packages, method not stated.	About 304,000 pushes examined. No count of tokens or accounts.
Whose account it is	Bloom sells endpoint security and GitHub owns npm.	Docker runs the registry and wrote the disclosure. It is the only source for its own checks.

Neither record establishes a real-world takeover, but the two statements are not the same kind. Docker states a finding after a defined check, with a stated limit. The npm sources say none is reported and that it is unknown. Reading them as one reassurance would be an error. The shared lesson is narrower: a name, a token or a badge is not an identity unless something checks it at the moment it moves. A neighbouring case on this site, the Tensorlake npm release, shows the same limit from the other side: valid provenance showed where a build ran, not that anyone reviewed what shipped.

What a hijacked registry token does and does not beat

A token that pushes under a legitimate name defeats the one control most teams rely on: trust in the name. The controls below work at different points. Each is read from its own source, with that source's stated limit. Digest pinning, signature checks and an internal allow-list are the ones that do not depend on the registry's account system being right.

Controls against a hijacked registry push, as each source describes them. The right-hand column gives the source's own limit or this briefing's reading, marked where it is inference.

Control	What it does here	Its limit
Pin by digest (Docker's build guidance; NCSC)	Docker: a pin means you "always use the same image version, even if a publisher replaces the tag". The NCSC says to prefer the checksum for important workloads.	Docker's blog: a digest pin "does not by itself prove publisher identity". A pin moved to a newly pushed digest accepts it. Docker's build guidance adds that pinning opts you out of automated fixes unless a bot proposes changes you review.
Verify signatures (Cosign, Notation)	Docker's blog: signatures prove publisher identity. Cosign uses short-lived certificates tied to an OIDC identity. An image pushed with only a registry token would not carry the expected signature (inference).	Only where the consumer enforces it, for example at cluster admission with Kyverno or Ratify. The NCSC: you still rely on the registry not to disclose or delete your images.
Docker Content Trust	Docs: a consumer with it on sees only signed tags, and an unsigned push does not replace a signed tag.	Retiring. Docker says the Notary v1 service shuts down on 8 December 2026, 56 days from 13 October (derived). Fewer than 0.05 per cent of Hub pulls use it, per Docker.
Immutable tags (Docker Hub, Beta)	Docs: once pushed, a tag cannot be overwritten or deleted, so an existing tag cannot be retargeted.	Default is that all tags are mutable. It does not stop a push of a new tag. It is marked Beta.
Organisation tokens and OIDC (Docker docs)	A personal token has one permission level for every repository the account can reach and cannot be limited to one. An organisation token can be limited to up to 50 repositories and to named scopes, can expire, and shows when it was last used. GitHub Actions can use OIDC with no stored token.	An organisation token is still a bearer secret. It does not work with Docker Desktop or Image Access Management. The default expiry is none.
Pull-through cache and internal registry	Docker's page: a registry can run as a pull-through cache. For a delimited set of images it suggests pulling them and pushing to a private local registry. The NCSC says to store every image you use in a secured registry.	Docker's page says a cache checks the remote for newer content on a tag pull, so a retargeted tag would be refreshed (inference). A pull by digest names fixed content. A cache is not an allow-list.
Activity logs (Docker Team and Business)	Docs: events include tag pushed, tag deleted and token created, updated or deleted, with the token named as the actor.	Docker Home keeps 30 days, so on 13 October it reaches back to 13 September, 17 days before the fix (derived). Longer history needs the API, and its retention is not stated. No event is listed for a token changing owner.

The UK: what the NCSC says, what Cyber Essentials covers, and when the ICO is involved

The NCSC's containerisation guidance, published and reviewed on 31 January 2024 (version 1.0), opens its running-containers advice with the image supply chain. Its goal is to "Ensure you have good reason to trust every container image you use". The listed controls are: prevent untrusted images running, take care with mutable tags, use reputable sources, verify origin, authenticity and integrity, protect and authenticate access to the registries you use, and store every image in a secured registry. It says to rely on technical controls and not on procedure alone, and to prefer the cryptographic checksum for important workloads. It adds that signature checks stop a registry inserting untrusted data undetected, while you still rely on the registry not to disclose or delete your images. That last point is this flaw's reach: pulls and deletes are what a signature does not cover. The guidance is read from the NCSC page.

The NCSC's blog of 4 June 2026 on software supply chain attacks, last modified 2 July, is about open source package registries and does not mention container registries or this flaw. It lists "maintainer account compromise" as a technique, where attackers steal credentials or tokens that let them update a trusted package, and its immediate actions include rotating exposed credentials, enforcing multi-factor authentication for registry accounts, using private or trusted registries where appropriate, and keeping sensitive credentials off developer workstations. Applying those to a container registry is analogy, not the NCSC's wording. The blog is here.

Cyber Essentials v3.3 (April 2026) does not start a 14-day clock for this. Its rule is that software in scope is updated within 14 days of the vendor's release for critical or high-risk vulnerabilities, and a fix the operator deploys to its own hosted service is not a release a customer installs. Nothing was released to apply on 30 September. What applies instead is the document's cloud-services wording. Cloud services are in scope and cannot be excluded. The applicant is "always responsible for ensuring all controls are implemented", but some can be implemented by the provider, and where the provider does it you must make sure it has committed to that in contract documents or documents the contract references. In the document's table, security update management sits with the provider for software as a service and with both parties for infrastructure and platform services, and user access control sits with your organisation in all three. Which row a container registry belongs to is a judgement the document leaves to the assessor: its examples do not list registries.

So the part of the document that bites is user access control, and it is thin on this subject. It asks that you control who has accounts and privileges, remove accounts no longer needed, and that authentication to cloud services always uses multi-factor authentication. It does not mention container registries, access tokens for automation or secrets. The word "tokens" in it means physical security keys, and "registry" appears only in the phrase "registry fixes", among the ways a vendor can ship a fix. Nothing in the document, as read, requires a review of the long-lived access tokens that automation uses (inference from its silence), so a certificate is not evidence of control over this risk. The document is the NCSC's PDF.

The ICO's guidance applies only if personal data was involved. A personal data breach there includes unauthorised access to personal data and alteration of it without permission, so a private image holding customer data that an impostor read, or a tampered image that then leaked personal data, would qualify. The duty is to report a notifiable breach to the ICO without undue delay and within 72 hours of becoming aware of it, to keep a record of every breach whether or not it is reported, and to be able to justify a decision not to report. The ICO says failing to notify can bring a fine of up to 8.7 million pounds or 2 per cent of global turnover. If Docker is acting as your processor for personal data in private repositories, the ICO says it must tell you without undue delay once it is aware, and the terms belong in your contract. Whether it is your processor is a contract question this briefing cannot answer. A notice of exposure, with Docker finding no evidence of exploitation, is not on its face a confirmed breach. The prudent course is to assess it and write the decision down. The guide is on the ICO site.

What to do, in the order worth doing

What could not be verified

• Docker's own checks. The 304,000 pushes, the conversions reviewed, the static analysis and the timeline are Docker's account of its own work. The reporters' page repeats Docker's figures and times and adds no separate measurement.
• The 765 days and the intervals. They are this briefing's arithmetic from Docker's stated start and end, labelled derived. Docker states neither the day count nor the 8-day gap.
• The bracketed time. Docker's bulletin prints the fix time as "approximately [19:10] UTC" with the brackets. The CVE record gives the same 19:10 UTC without them.
• Documentation catching up. Docker's convert-account page, as read, says the new owner receives a notification email and says nothing about consent. The bulletin says consent is now required. Whether the page lags is not stated.
• Security announcements page. Docker's docs security announcements page did not list this CVE when read. The bulletin is on its blog.
• NVD and the exploited catalogue. NVD showed no assessment and the catalogue did not list the CVE at the times stated above. Both can change within the hour.
• Whether free accounts have activity logs. Docker's page marks activity logs for Team and Business. That a personal account has none was not read and is not claimed.
• The reporters' Official Images worst case. Flagged by them as unconfirmed, and Docker's bulletin does not address it.
• Anything run. No test was made against Docker Hub, and none is described.

The question that exposes the gap

Docker's logs show that a token was used, not that it exists, and Docker Home reaches back 30 days. A flaw that stood for 765 days leaves the record of what it did in places a registry cannot see: your build system, your deployment history and your own copies of what you shipped. So ask the question the registry cannot answer for you. If a token had pushed an image under your name at any point since 26 August 2024, which record of yours would show it today, and how far back does that record go?

Key facts