As reported by The Hacker News, Docker has remediated a critical flaw in its Hub platform that for over two years allowed any registered user to impersonate another account at the registry layer. Tracked as CVE-2026-105445 and scored 9.4 under CVSS 4.0, the vulnerability lived in the personal-to-organization conversion path — a workflow that thousands of DevOps teams use routinely.
Why This Matters Beyond Docker
The technical root cause is narrow — PAT ownership transferred without confirmation — but the blast radius is everything Docker Hub exists to protect: trust in published container images. An attacker who weaponized this flaw could push malicious images under a legitimate publisher's namespace, pollute pull requests, or delete production-tagged images. That is not a credential theft problem. It is a supply chain integrity problem, and the industry has spent four years building SBOMs, signing frameworks, and attestation tooling specifically to defend against this class of risk.
What makes GhostPat — the name given by finders Peter Molnar and Krisztian Hozak — particularly insidious is that it required no action from the victim. No phishing, no stolen password, no compromised endpoint. The named organization owner was never asked to confirm and was never notified. A user could simply convert their own account, name a target as owner, and inherit registry-level authority for that target's repositories and any organizations they could access.
Vulnerability Details
| Field | Detail |
|---|---|
| CVE | CVE-2026-105445 |
| CVSS 4.0 | 9.4 — Critical |
| Affected Platform | Docker Hub (account conversion feature) |
| Exposure Window | August 26, 2024 – September 30, 2026 |
| Impact | Unauthorized push, pull, delete of images as any named org owner |
| Scope Limit | Registry only — no web UI, no password/2FA/email changes |
| Patch Status | Fixed server-side on September 30, 2026 — no client action required |
| Active Exploitation | None observed per Docker's investigation |
Who Is Most Exposed
Teams that converted personal Docker Hub accounts to organizations between August 2024 and the fix date should treat this as a potential integrity breach — not because exploitation is confirmed, but because detection was impossible from the victim's side. Organizations with large public image pull counts, CI pipelines pulling from Docker Hub without digest pinning, and teams that relied on namespace reputation rather than cryptographic verification are the highest residual-risk cohort.
The Verification Gap
Docker's advisory states no evidence of exploitation was found. That is reassuring but insufficient for a two-year window on a platform with millions of pulls daily. The flaw did not leave a log trail visible to the victim, because the victim was not a party to the conversion action. This means absence of evidence is not evidence of absence — a distinction CISOs communicating to boards should make explicitly.
What You Should Do
Immediate Actions
sha256 digests. Tags are mutable; digests are not. This is the single most effective control against this class of risk.Broader Hardening
- Implement image signing — Adopt cosign or Docker Content Trust (DCT) for any images you publish. Signature verification at pull time would have detected a malicious push under a legitimate name, regardless of how the attacker gained access.
- Review your container registry strategy — For high-trust environments, consider a private registry mirror or a managed alternative with stronger tenant isolation guarantees. Docker Hub is convenient; convenience and zero-trust supply chain security are in tension here.
- Map this to your SBOM and attestation program — If you are subject to Executive Order 14028 or NIST SP 800-218 requirements, document this incident in your risk register and verify that your attestation pipeline would have caught an unauthorized push.
The two-year exposure window is the real story. A 9.4 CVSS flaw in a platform that underpins global container distribution went undetected not because it was obscure, but because the design assumed trust in a conversion flow that never required consent from the affected party. That assumption is now publicly invalidated.
Shield53 assesses this as a high-impact, low-residual-risk event for most organizations — but a critical wake-up call for teams still relying on namespace reputation and tag-based pulls. The fix is applied. The lesson should be permanent.
