Critical Docker Hub Vulnerability Could Let Attackers Impersonate Users and Publish Malicious…

A flaw in Docker Hub's personal access token handling exposed a potential container supply chain risk, allowing attackers to publish images under trusted identities.

Docker has disclosed a critical security vulnerability in Docker Hub, tracked as CVE-2026–105445, that could have allowed attackers to impersonate other users and publish container images under trusted names.

The vulnerability affected personal access tokens (PATs) during the conversion of personal Docker Hub accounts into organizations. By exploiting the flaw, an attacker could potentially gain registry-level access associated with another user, depending on the token's permissions.

Docker fixed the issue on September 30, 2026, and reported no evidence of exploitation.

Although the flaw did not enable complete account takeover, it raised serious concerns about software supply chain security and the trust developers place in container images.

How the Docker Hub Vulnerability Worked

Docker Hub allows users to convert personal accounts into organizations while preserving existing repository names. This feature helps teams maintain compatibility with applications, deployment pipelines, and automated build systems.

However, a change introduced on August 26, 2024, created a security weakness in the conversion process.

During account conversion, personal access tokens belonging to the original account were transferred to the selected organization owner. Docker changed the token's ownership association without changing or revoking the underlying secret.

The new owner was not required to approve the transfer and did not receive a notification.

This created an opportunity for abuse.

An attacker could create a Docker Hub account, generate a personal access token, and convert the account into an organization while selecting a victim as its owner. The attacker would retain knowledge of the token secret, even though Docker Hub associated that token with the victim.

As a result, registry requests using the token could be authenticated as the targeted user.

In simple terms, the token's identity changed, but the attacker still possessed the credential needed to use it.

This was a credential ownership and authorization issue rather than a conventional password theft attack.

What Could an Attacker Do?

The vulnerability could have allowed unauthorized actions within Docker Hub's container registry.

Depending on the affected token's permissions and the victim's repository access, an attacker could potentially:

• Pull container images: Access repositories available to the affected identity.
• Target connected organizations: Potentially affect organizational repositories accessible through the compromised authorization context.
• Delete images: Remove container images from repositories where the token had sufficient permissions.
• Push malicious images: Publish modified or harmful images under trusted repository names.

The most concerning scenario involved publishing a malicious image under a legitimate repository name.

Developers frequently rely on trusted container images to build applications, deploy services, and run production workloads. If an attacker could replace or publish an image through an authorized-looking identity, downstream users might unknowingly deploy malicious code.

However, Docker clarified that the vulnerability did not provide access to the victim's Docker Hub website account. It could not be used to change passwords, email addresses, or two-factor authentication settings.

The impact was limited to registry operations and depended on the token's scope and associated permissions.

Why This Matters for Software Supply Chain Security

Container images are fundamental to modern software development. Organizations use Docker images to package applications, manage dependencies, and deploy workloads across development, testing, and production environments.

This ecosystem relies heavily on trust.

Developers often assume that an image published under a familiar repository name comes from the legitimate owner. A vulnerability that undermines that trust can introduce risks throughout the software supply chain.

A malicious image could potentially contain credential-stealing code, backdoors, cryptominers, or other harmful components. If integrated into automated build or deployment pipelines, such an image could expose multiple systems.

This is why container security involves more than scanning images for known vulnerabilities. It also requires strong identity management, token lifecycle controls, repository permissions, and reliable publishing processes.

The Docker Hub issue highlights an important principle: a valid credential can still create a security risk when its ownership and authorization are handled incorrectly.

How Docker Responded

Researchers Peter Molnar and Krisztian Hozak of mptrdev.com reported the vulnerability through Docker's vulnerability disclosure program.

According to Docker's security advisory, the company reproduced the issue using internal test accounts and deployed a production fix less than four hours after receiving the report.

The vulnerability's exposure window extended from August 26, 2024, at 20:33 UTC, until September 30, 2026, at approximately 19:10 UTC.

Docker also investigated account conversions that occurred during the affected period.

Its investigation included reviewing registry authentication logs, token records, usage data, and approximately 304,000 image pushes made using transferred tokens.

According to Docker, those pushes went to repositories associated with the converted organizations or their new owners. Investigators found no evidence of pushes to unrelated accounts.

Docker also inspected higher-risk public images without executing them. The investigation found no evidence of malware, cryptomining, credential theft, persistence mechanisms, or image tampering linked to the incident.

However, Docker noted a limitation: registry logs capture token usage, not the mere existence of a token. Consequently, the absence of recorded activity did not prove that every transferred token was harmless.

Docker therefore treated all transferred personal access tokens as potentially affected, including tokens that had not appeared in usage logs.

Security Measures Introduced by Docker

Docker notified affected users and organization owners on October 2, 2026.

On October 8, the company deactivated transferred tokens, except those that owners had specifically requested to retain.

Docker also confirmed that account conversion would no longer transfer personal access tokens.

Additional safeguards include plans for owner consent, notifications, and records of token ownership changes.

These changes aim to prevent credentials from silently changing ownership and to make future token transfers more transparent.

Docker stated that users who received no notification were not exposed and did not need to take incident-specific action.

What Docker Hub Users Should Do

Even with the vulnerability fixed, developers and administrators should review their credential management practices.

Here are several practical steps:

1. Review personal access tokens

Check existing PATs and revoke unfamiliar, unused, or unnecessary tokens. Follow Docker's official security advisory for incident-specific guidance.

2. Apply the principle of least privilege

Grant tokens only the permissions required for their intended tasks. Avoid using broad permissions when read-only or repository-specific access is sufficient.

3. Use organization access tokens for automation

For organizational workflows, consider Docker Hub organization access tokens where appropriate. These help separate automation credentials from individual user identities.

4. Secure container publishing pipelines

Protect build and deployment workflows, restrict who can publish images, and review repository permissions regularly.

5. Verify container images

Use image scanning, trusted publishers, image digests, and signature verification where supported. These controls can help detect vulnerable or unexpected images and reduce the risk of deploying untrusted artifacts.

6. Monitor registry activity

Review unusual pushes, unexpected image changes, and suspicious token usage. Monitoring should complement strong access controls rather than replace them.

Final Thoughts

The Docker Hub vulnerability demonstrates how a seemingly routine account conversion can introduce a serious security weakness when credential ownership is not handled safely.

Although Docker reported no evidence that attackers exploited CVE-2026–105445, the potential impact was significant. Unauthorized image publishing can undermine trust in software dependencies and expose organizations to supply chain attacks.

For developers, DevOps engineers, and security teams, the lesson is clear: protecting container infrastructure requires more than securing passwords. It also means managing tokens carefully, limiting permissions, monitoring registry activity, and verifying the integrity of software artifacts.

As container-based development continues to grow, secure identity management and trustworthy image publishing remain essential parts of a strong cybersecurity strategy.