For over two years, any Docker Hub user could silently redirect a Personal Access Token to impersonate you — no password required, no email notification, no trace on your end. Docker patched it in four hours once someone reported it. The flaw sat open for 25 months before that happened.
What Actually Broke
Docker Hub lets users convert a personal account into an organization. During that conversion, you name an existing Docker Hub account as the new org’s owner. That part works as expected. What didn’t work was what happened to the converting account’s Personal Access Tokens.
Starting August 26, 2024, the conversion process silently reassigned all PATs from the original account to the designated owner — without rotating the token secrets, without notifying the new “owner,” and without asking for their consent. The attacker kept the token secret. The registry now treated that token as belonging to the victim.
The exploit required no sophistication:
- Create any Docker Hub account
- Generate a Personal Access Token
- Convert the account to an organization, naming your target as owner
- Use the PAT you still hold — now authenticated as your target
With a token scoped for read-write, an attacker could push images to the target’s repositories, pull from private repos, or delete images. The one thing it couldn’t do: access the Docker Hub web interface or change account credentials. This was registry-API access only — which is precisely the attack surface that matters for supply chain attacks.
Why “Push Images as Someone Else” Is a Serious Problem
Docker Hub processes 11 billion image pulls per month. When your CI/CD pipeline pulls trustedteam/baseimage:latest, it doesn’t verify who actually pushed that tag — it trusts the namespace. An attacker who could authenticate as a trusted developer or a widely-used open source maintainer could replace that image with something malicious, and every downstream build would pull it automatically.
This isn’t a hypothetical concern. In 2025, researchers found 35+ Docker Hub images — including Debian builds — still carrying the XZ Utils backdoor nearly a year after it was disclosed. Images built on top of those bases inherited the infection. The XZ attack required two years of social engineering and maintainer trust cultivation. GhostPat required none of that: any account, any target.
That’s why Docker classified this as a software supply chain risk and assigned it a CVSS score of 9.4 — one notch below the theoretical maximum.
The Timeline
The bug was introduced on August 26, 2024, in a code change to the account conversion feature. It sat undetected for 25 months. On September 30, 2026, a security researcher reported it through Docker’s Vulnerability Disclosure Program. Docker confirmed the report and deployed a fix to production the same afternoon — four hours after the initial report.
Docker reviewed approximately 304,000 pushes made with transferred tokens and found no evidence of exploitation. On October 2, affected users received an email with the subject line “Docker Hub Vulnerability Identified & Resolved.” Docker deactivated all identified transferred PATs except those owners explicitly requested to retain. The full technical details are in Docker’s official security advisory.
Four hours to patch critical infrastructure is legitimately fast. Twenty-five months undetected is a different conversation entirely.
What You Should Do
If you didn’t receive Docker’s October 2 email, you were not affected. No action is required for most users.
Regardless, use this as a forcing function to tighten up your Docker Hub security posture:
- Audit your PATs. Go to Account Settings > Security and delete any tokens you don’t actively use. Token proliferation is the surface area that makes flaws like this dangerous.
- Pin images by digest, not tag. Tags are mutable. A digest (
image@sha256:abc123) is not. Pinning by digest means a replaced image won’t affect your build even if an attacker controls the tag. - Check your org ownership. If you’ve ever been named as an owner during an account conversion you didn’t initiate, review what PATs exist under your account.
- Use Docker Content Trust for signed images in production environments where verification matters.
The Bigger Picture
Container registries have become infrastructure. The images in Docker Hub are as load-bearing as the code in your repositories — sometimes more so, because they carry the runtime environment, the OS libraries, and every transitive dependency your application needs. Yet most teams treat registry tokens with far less discipline than they treat code commit access.
GhostPat didn’t require a sophisticated attacker. It required a Docker Hub account and knowledge that the conversion feature existed. The fact that it went undetected for over two years is the real story — not because Docker is uniquely negligent, but because this class of token-transfer logic is scattered across every platform that supports organizational account structures. BleepingComputer’s full breakdown covers Docker’s investigation in detail. It’s worth checking whether the tools you use have done the same audit Docker just completed.













