Whose Authority Does Your Docker Hub Token Carry?
A registry credential has at least two histories: who knows its secret, and whose permissions the service applies when it is used. Those histories should agree. Docker Hub’s GhostPat disclosure shows why reviewing a token only by its familiar name or apparent current owner can miss the relationship that matters.
Docker’s 12 October advisory describes CVE-2026-105445, fixed on 30 September. From 26 August 2024, account-to-organisation conversion could reassign personal access tokens to a named owner, keeping their secrets unchanged, without that owner’s confirmation or notification. Conversion no longer transfers those tokens.
Within token scope, registry pulls, pushes or deletions were possible, not web-interface access or password, email or two-factor changes. Docker notified identified exposed users on 2 October and deactivated transferred tokens on 8 October, except opt-outs.
A working secret is not proof of legitimate ownership
The researchers’ disclosure describes private pulls and pushes using consenting test accounts. Their warning about attacker-chosen token labels is practical: a recognisable description does not establish who created the secret. This was a demonstrated authority-transfer flaw, not a reported breach of every namespace or proof that official base images were compromised.
In an organisation, a friendly token label often becomes shorthand for a service: nightly-build, deployment or backup. That is useful for finding the person who understands the job. It is weaker as an authentication record. Ask who issued the credential, which automation should possess it and which repository permissions that automation genuinely needs. The description alone cannot answer those questions.
What Docker’s investigation can and cannot establish
Docker examined about 304,000 pushes and found no evidence of exploitation. It cautions that unused transferred secrets leave no registry-use trace. It says users without an exposure email were not exposed through this flaw and need no flaw-specific action. These are Docker’s findings and scope, not an independent forensic guarantee.
For notified recipients, preserve the notice and reconcile its token identifiers with the business services that should use them. A completed platform remediation and an explained local credential inventory are different acceptance records. Do not use an unrecognised credential as evidence that an attack occurred, but do not discard the question simply because a platform investigation found no malicious activity either.
Route the work to the people who own identities and automation together. A platform notice should not become a generic request to update an unrelated package. Give the service owner the exact question that still needs an answer, and keep any local credential decision separate from the vendor’s completed platform action.
Current conversion guidance changes the handover
Docker’s current conversion documentation requires a separate Docker ID for the organisation owner. Repository collaborators are removed and must be invited into the organisation and given team access. Existing automated builds appear under the new owner. Conversion is permanent. Those details belong in a planned handover, not an improvised credential test.
That distinction gives a team two workstreams. Preserve the repository identity that consumers depend on, while deliberately establishing the new authentication relationship. The existence of a successful image pull proves that one operation worked at that moment. It does not prove that every publisher, deployment system and recovery task has the intended owner or has stopped using an obsolete secret.
Choose the credential for the workload
The current access-token guidance distinguishes personal tokens, tied to an individual’s account, from organisation-owned tokens that can be restricted by repository and operation. It recommends the latter for production pulls and organisation automation. They are not a drop-in answer for every tool: organisation tokens do not work with Docker Desktop or Image Access Management.
For GitHub Actions, the same guidance describes an OIDC connection that exchanges short-lived workflow identity for Docker access rather than storing a long-lived token. It requires an organisation owner and a Docker Team or Business subscription. Automation outside GitHub Actions may instead need an organisation token. Choose on the basis of the actual environment, not a generic instruction to replace every credential with the newest option.
Test the handover without hiding the old dependency
Consider a hypothetical team separating a founder’s personal account from a shared product namespace. One pipeline publishes images, two deployment systems pull them and a recovery job runs only during an incident. The publishing pipeline is the first service migrated. A successful build is encouraging, but it says nothing about the recovery job that has not run yet.
Give each service an owner, its intended operations and a supported replacement path. Test the publisher and consumers independently, then include the less frequent recovery operation. Retire old credentials through a controlled change only after understanding their legitimate dependencies. If an unexplained token must be revoked promptly, record which services may fail and who can restore them safely. Do not keep an unknown secret indefinitely just to avoid investigating that dependency.
The durable lesson is not that a particular token label should be distrusted forever. It is that secret possession, recorded identity and authorised repository operations need a shared audit trail. A credential should not outlive its explanation, and a change of organisation ownership should not silently become a change of someone else’s authority.
Primary evidence
The Docker advisory supplies the incident chronology and investigation limits. GhostPat supplies the researchers’ test-account findings. Docker’s current conversion and access-token documents supply the post-fix behaviour and supported credential choices. The handover example is BlackTree’s own hypothetical analysis.
