Docker Hub CVE-2026-105445: What Operators Should Do

Quick answer: Docker has fixed CVE-2026-105445, a critical Docker Hub identity flaw that could reassign an attacker-controlled personal access token (PAT) to another user during personal-account-to-organization conversion. Docker says affected users and organization owners were emailed on October 2, 2026, and identified transferred tokens were deactivated on October 8 except where an account holder opted out. If you received that notice, investigate the listed tokens, registry activity, images, CI credentials, and downstream deployments. If you did not receive it, Docker says your account was not exposed through this flaw; a routine token and automation review is still sensible.

This is a source-based operator analysis published October 14, 2026. WealthLab did not reproduce the vulnerability, inspect Docker's internal logs, or test an affected account. It contains no affiliate links.

What happened?

Docker's October 12 advisory says that, from August 26, 2024 until the production fix on September 30, 2026, converting a personal Docker Hub account into an organization also reassigned that account's PATs to the person named as the new organization owner. The token secret was not rotated or revoked, and the recipient was neither asked to consent nor notified.

An attacker could therefore create a throwaway account and PAT, convert the account to an organization, designate a target user as owner, and retain the still-valid secret. Within the PAT's scope, that token then authenticated to the registry as the target. Docker says this could permit pulling, pushing, or deleting images in repositories available to the target, including organizations the target could access.

The independent researchers' technical disclosure reports two reproductions using consenting test accounts. They demonstrated registry login as the target, private-image reads, and pushes under the target and an organization available to that target. Their worst-case discussion about Docker Official Images was explicitly flagged as unconfirmed; it should not be repeated as an observed compromise.

Who is affected?

What Docker found—and what it cannot prove

Docker says it reviewed every account conversion in the exposure window, correlated registry authentication and IAM records, examined approximately 304,000 pushes made with transferred tokens, and statically analyzed the highest-risk public images. It reported no evidence of exploitation, unrelated-account pushes, malware, cryptominers, command-and-control activity, credential harvesting, persistence, or tampering.

That is meaningful vendor investigation evidence, not proof that no misuse occurred. Docker also states the key limitation: registry logs show when a token is used, not merely that a secret exists. An unused transferred token leaves no registry-use trace. The finding should therefore be read as “no evidence found in the reviewed records,” not “exploitation was impossible.”

Immediate response checklist for notified users

1. Preserve the notice and scope. Record the token descriptions and creation dates Docker identified, the affected user or organization, and relevant dates. Keep sensitive values out of tickets and chat.
2. Confirm deactivation. In Docker Hub Account settings → Personal access tokens, verify each identified token is inactive or revoked. Revoke any unknown or unnecessary token. Do not trust a familiar token name: descriptions can be chosen by whoever created the token.
3. Replace automation credentials deliberately. Find CI/CD jobs, build servers, deployment hosts, registry mirrors, secret stores, and developer systems that used the affected identity. Issue new least-privilege credentials, update one integration at a time, verify it, then remove the old secret.
4. Review registry activity. Examine pulls, pushes, deletes, repository creation, tag changes, and organization membership changes across the exposure window. Prioritize private repositories and images deployed with elevated host, network, or cloud privileges.
5. Validate image history. Compare expected build provenance, source commits, CI run records, image digests, signatures or attestations, and deployment manifests. A tag can move; use immutable digests when reconstructing what actually ran.
6. Check downstream deployments. Identify Kubernetes workloads, Compose stacks, CI runners, developer machines, and mirrors that pulled a questioned tag. Scanning an image is useful, but a clean vulnerability scan does not prove the image came from the intended source or lacks malicious application logic.
7. Escalate unexplained evidence. If you find an unknown token, push, digest, repository, or organization, preserve logs before cleanup and contact Docker Support. Follow your incident-response process for credential exposure and software supply-chain risk.

Do not rotate blindly

Credential rotation can cause an outage if an undocumented pipeline still depends on the old token. Build a dependency list, create a least-privilege replacement, update and verify each consumer, and only then revoke the previous credential when the incident does not require immediate containment. For a suspected active compromise, containment takes priority; accept controlled deployment disruption rather than leaving a known attacker credential valid.

Docker's current token documentation recommends organization access tokens for organization-wide automation because they are not tied to a person's account. That can reduce ownership ambiguity, but changing token type does not remove the need for narrow scopes, expiration, secure storage, usage review, and an inventory of every consumer.

Hardening beyond this CVE

• Separate human and automation identities. Do not make a developer's broad PAT the permanent credential for organization publishing.
• Use the least registry scope. A pull-only deployment credential should not be able to push or delete images.
• Prefer expiry and rotation. Docker allows PAT expiration and displays last-used information. Review tokens on a defined cadence.
• Pin production images by digest. Tags are useful release labels, but a digest identifies the exact manifest selected at deployment time.
• Record provenance. Keep the source revision, build run, builder identity, SBOM, attestation, and resulting digest together where the workflow supports them.
• Protect CI secrets. Restrict which branches, environments, and jobs can read registry credentials. Do not expose secrets to untrusted pull-request code.
• Monitor the registry and deployments. Alert on unexpected repository creation, publishing identities, tag movement, digest changes, and production pulls outside the normal release path.

What not to do

• Do not rebuild every server or upgrade Docker Engine solely because of this disclosure; the published flaw was in Docker Hub's identity flow.
• Do not claim Docker Official Images were compromised. The researchers described that as an unconfirmed worst case, and Docker says its review found no evidence of exploitation.
• Do not assume revoking one token proves every published image is trustworthy. Credential containment and artifact verification answer different questions.
• Do not paste PATs, full CI environments, or secret-bearing configuration into an incident ticket.
• Do not use mutable tags alone to reconstruct what was deployed during the exposure window.

Fit and non-fit

This incident-response workflow fits teams that received Docker's notice, publish images to Docker Hub, or operate automation under user-linked credentials. A lighter hygiene review fits teams that did not receive the notice but have accumulated old PATs or undocumented CI secrets.

This article is not an Engine remediation guide, a malware-removal procedure, or proof that a particular image was safe or compromised. Operators with evidence of unauthorized publishing need artifact-specific investigation and may need professional incident-response support.

Evidence boundary

WealthLab reviewed Docker's October 12 advisory, Docker's current PAT guidance, the researchers' public technical disclosure, and independent reports published October 13 by BleepingComputer and The Hacker News. We did not reproduce the conversion flow, receive an affected-user notice, inspect the approximately 304,000 pushes, validate Docker's static analysis, or test the deactivation process. Scope and “no evidence of exploitation” findings are attributed to Docker; reproduction details are attributed to the researchers.

Related WealthLab guides

• Docker VPS Production Checklist
• VPS Firewall Setup for Docker Apps
• Ghost Docker Backup and Restore Guide
• How to Install Hermes Agent on Linux Safely

Sources checked October 14, 2026

• Docker: CVE-2026-105445 security advisory — primary source for scope, timeline, vendor investigation, remediation, and affected-user guidance.
• GhostPat researcher disclosure — primary research account for reproduction and demonstrated registry impact.
• Docker Docs: create and manage personal access tokens — current token-management and organization-token guidance.
• BleepingComputer, October 13 — independent reporting corroborating the disclosure and response timeline.
• The Hacker News, October 13 — additional independent coverage checked against primary sources.