DEV Community

Anoymask
Anoymask

Posted on

Docker Hub CVE-2026-105445: PAT Reassigned to Target User During Account-to-Organization Conversion

#security #threatintel

1. Basic Information

2. Overview

This vulnerability allows an attacker to create a personal access token, convert their account into an organization, and designate a target user as the owner. The personal access token is reassigned to the target's permissions while retaining the token secret, enabling the attacker to pull, push, and delete container images under the target's identity.

3. Attack Flow

The following attack and exploitation path is confirmed by public information, distinguishing between observed facts, reproduction experiments, and feasibility.

Target Identity Spoofing via Personal Access Token Reassignment

  1. An attacker creates a personal Docker Hub account, generates a personal access token with registry access scope, and retains the secret.
  2. The attacker converts the account into an organization and designates an existing target Docker Hub user as the new owner.
  3. The vulnerable flow changes only the personal access token owner record to the target without rotating the secret or providing notice or consent to the target.
  4. When the attacker authenticates to the registry using the retained secret, the personal access token operates under the target's identity and scope.
  5. If the token scope and target permissions allow it, the attacker could pull, push, or delete images and publish a malicious image under a legitimate name. Docker found no evidence that these downstream actions occurred in production.

4. Attacker Positioning and Execution Location

  • A remote user who can create their own account and personal access token on Docker Hub and execute an account-to-organization conversion.

5. Perspective of Victims and Administrators

  • Users: Target users receive no confirmation or notification when designated as an owner, and checking account screens does not reveal that an attacker retains the secret.
  • Administrators: Visible through account conversions, personal access token owner changes, registry API access using target identities, unusual image pushes or deletes, and digest changes.

6. Success and Failure Conditions

Success Conditions

  • Converting the attacker account into an organization and designating the target user as the owner during the vulnerable timeframe.
  • The attacker retaining the personal access token secret created prior to conversion, with a token scope permitting the target operation.
  • The target user having access to the target repository or organization.

Failure Conditions and Mitigations

  • Using the post-fix conversion introduced by Docker on September 30, 2026.
  • Revoking or deactivating transferred personal access tokens and migrating to organization access tokens.
  • Restricting registry writes through signing, policies, digest pinning, and approvals.

7. Impact upon Success

  • Docker image pulls, pushes, and deletes under the target's identity.
  • Publication of malicious images to legitimate repositories and potential downstream supply chain compromise.
  • Disruption of audit trails based on the target identity.

8. Observable Logs

The following items are candidates for investigation within your organization. Distinguish between facts observed in public information and telemetry that should be verified internally.

  • Email: Check for the October 2, 2026 email with the subject "Docker Hub Vulnerability Identified & Resolved" and the list of affected tokens.
  • Proxy / SWG / DNS: Check for unusual pushes or deletes to registry-1.docker.io and auth.docker.io, along with source IPs and user agents utilizing the tokens.
  • Endpoint / EDR: Check for the affected personal access tokens, docker login credentials, push commands, and image build artifacts stored on CI runners or developer workstations.
  • Identity / IdP: Verify Docker Hub account conversions, organization owner designations, personal access token owner changes, and registry authentication under target identities.
  • SaaS / Cloud: Review Docker Hub audit and usage data, repository pushes and deletes, tag and digest changes, organization memberships, and personal access token metadata.
  • Network: Monitor registry API accesses and large layer uploads from unusual sources, regions, or ASNs.

9. Attack Success Determination

Confirmed by Public Information

Malware Execution or Authentication Success Confirmed

  • Scope: Verification environment using internal Docker test accounts.
  • Basis: Docker reproduced the reassignment of personal access tokens. This is an issue where registry authentication succeeds as the recipient user using the unchanged token secret. Regarding production environments, no evidence of exploitation was found after reviewing approximately 304,000 pushes.

Internal Determination Criteria

  • Correlate requests, responses, processes, authentication, data access, and external transmissions chronologically to separate contact from success.
  • Do not determine success based solely on a single alert not present in public disclosures.

10. Investigation Playbook

  • Investigation Origin: Start from Docker notifications, unfamiliar personal access tokens, image changes following account conversions, or abnormal pushes under target identities.
  • Initial Verification: Check for notifications, conversion timestamps, personal access token descriptions, creation dates, scopes, last usage, target repositories, and deactivation status as of October 8.
  • Endpoint and Server Investigation: Preserve CI/CD secret stores, developer credential helpers, runner logs, image build contexts, SBOMs, and signatures.
  • Authentication and Cloud Investigation: Check Docker user and organization memberships, owner designations, token owner history, source IPs, and registry authentication.
  • Subsequent Actions: Trace malicious layers, entrypoint modifications, credential harvesters, cryptominers, command and control activity, and downstream deployments and execution.
  • Containment: Revoke the affected personal access tokens, temporarily freeze image tags, rebuild and sign from trusted commits, and notify downstream parties of digest updates.
  • Determination Categories: Separately assess token reassignment, registry authentication, image pushes, downstream pulls, container execution, and subsequent compromises.

11. Defense and Detection Ideas

  • Single Events: Detect events where an existing personal access token is used under a new owner identity immediately after an account conversion, or image deletes and pushes from unusual sources.
  • Chronological Correlation: Correlate account creation, personal access token creation, organization conversion, target owner designation, and registry pushes under the target identity.
  • Threat Hunting: Search for conversions and personal access token owner changes occurring on or after August 26, 2024, multiple identities using the same token, and unexpected digests for legitimate images.
  • Log Limitations: Unused transferred personal access tokens leave no registry logs, and presence alone does not determine whether exploitation occurred.
  • Priority Mitigations: Prioritize revoking all affected personal access tokens, adopting organization access tokens, enforcing owner consent, signing images, digest pinning, and verifying provenance.

12. Facts / Inference / Hypothesis

Facts

  • Docker Hub account-to-organization conversions changed the personal access token owner record of the source account to the new organization owner starting August 26, 2024.
  • Token secrets were neither rotated nor revoked, and no confirmation or notification was sent to the designated owner.
  • Attackers could create personal access tokens on their own accounts, convert them to organizations, and designate targets as owners to obtain tokens with target permissions while retaining the secrets.
  • Docker verified that a reassigned personal access token could authenticate to the registry as the target. The token scope and target permissions could allow image pulls, pushes, and deletes, but these downstream operations were not established as having occurred in production.
  • The vulnerability did not directly allow access to Docker Hub web UIs, passwords, emails, 2FA settings, or account takeovers.
  • Docker fixed the issue in under four hours from report on September 30, 2026, and discontinued personal access token transfers during conversions.
  • Docker notified affected users on October 2, 2026, and deactivated transferred personal access tokens on October 8, except those opted out.
  • Docker investigated approximately 304,000 pushes, registry authentications, and IAM token records, finding no evidence of exploitation; however, because unused tokens leave no logs, all transferred personal access tokens were treated as potential impact targets.

Inference

  • Pushing malicious images to legitimate namespaces can lead to supply chain compromises if downstream CI/CD pipelines or automated updates do not pin signatures or digests.
  • Avoiding the reuse of personal access tokens for organization automation and instead using organization access tokens with explicit owner consent reduces ambiguity in credential ownership.

Hypothesis

No additional hypotheses. Unverified items are listed in section 14, "Unresolved Points and Additional Investigation."

13. MITRE ATT&CK Mapping

ID Technique Confidence Basis
T1078 Valid Accounts high Authenticates to the Docker registry as the target identity using reassigned, valid personal access tokens.
T1195.002 Compromise Software Supply Chain medium Malicious images can be pushed under legitimate repository names, potentially impacting downstream users.

14. Unresolved Points and Additional Investigation

  • The number of users and organizations notified of the impact.
  • The number and rationale for transferred personal access tokens that remained valid past October 8, 2026, due to opt-outs.
  • The existence of undetected instances where third parties created personal access tokens and subsequently abused the same flow.

15. Impact on SOCs and Organizations

Organizations operating Docker Hub for CI/CD or container distribution should verify whether they received the October 2 notification, check personal access token owners, creation dates, and last usage, review account conversions prior to September 30, and inspect image push histories. Critical images should be verified by digests, signatures, and provenance rather than tags alone, and personal access tokens must be removed from organization automation.

16. Summary by Role

  • SOC Teams: Correlate account conversions, token owner changes, registry authentications under target identities, and post-push image differentials, accounting for the limitation that unused tokens leave no logs.
  • Administrators: Revoke unknown or unnecessary personal access tokens, migrate organization automation to organization access tokens, and pin critical images using signatures and digests.
  • Users: If notified by Docker, review and revoke the specified personal access tokens and report any unfamiliar image changes to administrators.

Top comments (0)