A critical flaw in Docker Hub, the default public registry for software container images, could for about two years have let an attacker obtain a working key that acted as another user, potentially allowing tampered images to be published under trusted names, BleepingComputer reported Tuesday. Docker says it found no evidence anyone used it, but the case shows how a quirk in account management can turn into a software supply-chain risk for every organization that pulls images from the registry.

What Happened

Docker disclosed the issue, tracked as CVE-2026-105445, in an advisory posted Oct. 12 by security chief Mark Lechner. The problem sat in a feature that lets a personal Docker Hub account be converted into an organization account. Starting Aug. 26, 2024, the conversion also handed the old account's personal access tokens, long-lived keys used by scripts and build systems to log in, to whichever existing user was named as the new owner. The tokens kept the same secret, and the named owner was neither asked nor told.

That opened a simple path, according to Docker. An attacker could create an account, generate a token, convert the account and name a target as owner. The attacker still held the token, which now authenticated at the registry as the target. Within the token's permissions, that could mean pulling, pushing or deleting images in the target's repositories and in organizations the target could reach. The token did not give access to the Docker Hub website and could not be used to change a password, email address or two-factor settings.

RelatedSuspected Chinese Spies Exploited BeyondTrust Remote Support Flaw Since August, Google Says

Docker says researchers Peter Molnar and Krisztian Hozak reported the flaw Sept. 30 at 11:40 a.m. Eastern time, and a fix was in production at about 3:10 p.m. the same day. The fix stopped tokens from moving during conversion.

No Evidence of Exploitation

Docker says it traced every account conversion since August 2024 against its registry logs and examined about 304,000 image pushes made with transferred tokens. Each landed in the converted organization's own repositories or the new owner's own repositories, never in an unrelated account, and in most cases both accounts belonged to the same person or team. A static review of the highest-risk public images found no malware, cryptocurrency miners or signs of tampering. "We found no evidence that the vulnerability was exploited," the advisory says.

Docker acknowledges a limit: its logs record when a token is used, not that it exists, so a transferred token that was never used leaves no trace. It therefore treated every token that moved during the window as potentially affected. It emailed those users and organization owners Oct. 2 and deactivated the transferred tokens Oct. 8, except where holders asked to keep them. Users who did not get the email were not exposed, Docker says.

Why It Matters

Container images are the packaged software that companies download and run in their own cloud and data center environments, often automatically. A publisher identity that can be borrowed is a supply-chain weak point: a poisoned image under a familiar name would flow to downstream users who trust that name. Docker said it rated the flaw critical for that reason.

The flaw was not a coding error in the usual sense but a gap in business logic, how ownership of credentials changes hands. For boards and technology leaders, it is a reminder that third-party developer platforms carry identity risks that sit outside a company's own controls, and that personal tokens tied to individual employees are a fragile basis for automated build pipelines.

What to Watch

Docker recommends that users review their personal access tokens and revoke any they do not recognize or no longer use, and that organizations run automation on organization access tokens rather than a person's token. The company says it will add a consent step and notification before anyone is named an organization owner, keep an auditable history of token ownership changes and review other flows that change who owns a credential. Security teams may also want to check whether their own internal platforms move credentials when accounts are merged or converted.