Docker Hub CVE-2026-105445: tokens after account conversion

On 12 October, Docker disclosed CVE-2026-105445 in Docker Hub. The company deployed a service-side fix on 30 September and reported finding no evidence of exploitation. That is the provider’s review finding. Source: the Docker security advisory.

The CVE record published by Docker describes incorrect privilege assignment during account-to-organisation conversion. A PAT could receive another user as its owner while retaining its original secret. Within its scopes, it could then pull, push or delete images as that user.

Breachroad’s conclusion: owners of accounts covered by the notice should establish which tokens and workflows were associated with them. Teams publishing images also need a clear record of responsibility for automation permissions and how artefact provenance is confirmed. The review plan below is our recommendation.

Establish the notification scope first

Docker says it notified exposed users and organisation owners on 2 October. According to the provider, those who did not receive that notification were not exposed through this mechanism and need take no action for this CVE.

We recommend that a recipient of a corporate notification maps it to the correct account and organisation and preserves the provider’s stated scope. If the message raises questions, verify it through a known support channel and service owner. Do not automatically extend findings about one account to the entire corporate registry estate.

The CVE record marks the issue as affecting an exclusively hosted service. In our assessment, the task associated with this notice should therefore focus on the account, tokens and available records. Updating a local container engine does not demonstrate that those findings were established.

A token needs business and technical owners

In our plan, an automation review answers four questions:

1. Which workflow uses the permission? Identify the pipeline, scheduled job or integration and its environment. A token name alone does not explain that relationship.
2. Who authorised access? Establish the account custodian and the person responsible for published images. The record should survive staff or team changes.
3. Which actions are required? Distinguish reading, publishing and deletion, alongside repository scope. Access should match the actual task.
4. How does use end? Define withdrawal conditions, secret replacement and verification of the dependent workflow.

This is a general access hygiene review that can also take place outside handling this CVE. It does not imply that all tokens or all Docker Hub images were compromised.

Verify the outcome of a secret change

If the notification scope or an organisational decision requires replacing a token, we recommend coordinating the sequence with the pipeline owner. Establish where associated credentials are configured, who updates them and how completion will be verified.

Afterwards, record verification of required functions and withdrawal of earlier permissions under the agreed plan. Preserve identifiers and review results without placing secret values in the ticket. A message that one entry was changed successfully does not describe every dependent integration.

Image provenance needs evidence

We suggest linking approved publications to the build workflow, artefact identifier and available activity records. A repository name or tag describes a destination and publication label; the release owner also needs evidence of which workflow output was approved for use.

If an unexpected publication appears, invoke established incident handling. Preserve available logs, compare permission scope and determine which environments may have used the artefact. A later token change does not explain the complete earlier history.

A training scenario for the CI/CD team

A company uses a former employee’s token, but nobody can identify all dependent pipelines. This is a hypothetical discussion scenario, rather than an account of a victim of this CVE.

Ask participants to establish the owner, necessary access scope and evidence of a successful change. The aim is to practise publishing responsibility and control over automation credentials.

For broader context, read our guide to CI/CD security. Developers and administrators can discuss similar scenarios in our cybersecurity training for organisations.