On September 30, 2026, security researchers reported a vulnerability in Docker Hub’s identity and access management through our Vulnerability Disclosure Program. We confirmed the report and deployed a fix to production the same afternoon, less than four hours after receiving it. We then reviewed every account conversion back to the date the flaw was introduced, and on October 2, notified every user and organization owner whose account could have been impacted by this vulnerability. This post explains what the vulnerability was, what it could and could not do, what we found, and what we have changed. We want to thank Peter Molnar and Krisztian Hozak of mptrdev. com for finding the issue, reporting it responsibly, and coordinating disclosure with us. Their technical write-up is available at ghostpat. com . This issue is tracked as CVE-2026-105445. Was I or any member of my organization exposed to the vulnerability? On October 2 at 5:30PM EST, we sent out an email with the subject line “Docker Hub Vulnerability Identified & Resolved” to the limited number of users exposed to this vulnerability. If you did not receive an email, you and any members of the organizations you administer were not exposed and there are no actions for you to take. What the vulnerability was

Docker Hub lets you convert a personal account into an organization. People do this because Hub has no way to move a repository from one account to another: conversion is how alice/app becomes an organization-owned alice/app without breaking every Docker pull that references it. During conversion, the user names an existing Docker Hub account as the new organization’s owner. Beginning August 26, 2024, conversion also re-assigned the converted account’s personal access tokens (PATs) to that new owner. It did this by changing the token’s owner record, without rotating or revoking the token secret. The named owner was not asked to confirm and was not notified. Together, those two gaps made the following possible:

An attacker creates an account and generates a PAT on it. The attacker converts that account to an organization and names a target user as the owner. The attacker’s PAT is re-assigned to the target user. The attacker still holds the secret and the PAT remains active now with the target user’s scope. The token now authenticates to the registry as the target user. What an attacker could and could not do

Within the scope of the token, a re-assigned PAT acted as the target user at the registry level, meaning an attacker could potentially pull, push, and/or delete images in the target’s repositories and in organizations where the target had access. Because that includes publishing images under a legitimate name, we treated this as a software supply chain risk and rated it critical. The vulnerability did not give access to the Docker Hub web interface, and it could not be used to change the target’s password, email address, or two-factor settings, or to take over the account. The exposure window ran from August 26, 2024, 20:33 UTC, until the fix was deployed on September 30, 2026, at approximately [19:10] UTC. Timeline (all times U. S. Eastern)

Sept 30, 11:40 AM: Report received at security@docker. com. Sept 30, ~1:30 PM: We independently reproduced the issue with internal test accounts. Sept 30, ~3:10 PM: Fix deployed to production and verified against the original proof of concept. Conversion no longer transfers PATs. Sept 30, ~3:23 PM: Documentation updated to state that PATs do not transfer and must be recreated by the new owner, with organization access tokens recommended…