Skip to content
Thursday, October 22, 2026AboutContactRSS
Vulnerabilities

Verify Docker Hub Token Permissions After Critical Impersonation Flaw Fix

Docker patched a critical flaw that let attackers use tokens they controlled to impersonate users and tamper with container images in the registry.

Illustration: A white ceramic coffee cup sits on a cluttered desk next to a sleek silver laptop.
AI-generated illustration: Shell Bulletin

Key points

  • CVE-2026-105445 allowed token reassignment during account-to-organization conversion without secret rotation.
  • Attackers could push, pull, or delete images in target repositories using the reassigned token.
  • Docker deployed a fix on September 30, 2026, and found no evidence of exploitation.

Docker resolved a critical vulnerability in Docker Hub on September 30, 2026, that allowed authenticated attackers to impersonate other users within the container registry. The flaw, tracked as CVE-2026-105445, enabled threat actors to use personal access tokens they controlled to authenticate as target users, granting them the ability to manipulate container images.

The vulnerability existed in the feature that converts personal accounts into organizations. When a user converted their account, they designated an existing user as the organization owner. Docker Hub reassigned the original account’s personal access tokens to this new owner without changing the token secrets or obtaining consent, according to BleepingComputer. This meant the attacker retained access to the token while it now represented the victim’s identity at the registry level.

Context and Background

Docker rated the issue as critical with a CVSS score of 9.4, citing software supply chain risks. An attacker could publish malicious images under a legitimate user’s name, potentially distributing compromised code to downstream consumers. The flaw was introduced on August 26, 2024, when the conversion feature began transferring token ownership without rotating secrets, The Hacker News reported.

Docker stated that the vulnerability did not grant access to the Docker Hub web interface. Attackers could not change passwords, email addresses, or two-factor authentication settings, nor could they take over the victim’s full account. The exposure was limited to registry operations such as pulling, pushing, or deleting images within the scopes defined by the token.

Who Is Affected

The vulnerability affected Docker Hub users whose accounts were converted to organizations during the exposure window. Organizations and individual users who had their tokens reassigned were notified on October 2, 2026. Docker deactivated transferred personal access tokens on October 8, except for those whose owners explicitly requested to keep them active.

Docker examined 304,000 image pushes made with transferred tokens and analyzed high-risk public images, finding no evidence of exploitation, according to Cyber Security News. The company deployed the fix to production less than four hours after receiving the vulnerability report on September 30, 2026.

What to watch

Monitor Docker Hub communications for updates on token deactivation status. Review repository access logs for any unexpected image pushes or deletions during the exposure window. Verify that all personal access tokens used in automated workflows are valid and have not been compromised. Watch for vendor advisories regarding broader supply chain integrity checks.

What made it possible

Teams usually encounter this class of flaw when systems transfer credentials without invalidating the original secret. The weakness lies in assuming ownership change implies secret rotation. This technique serves the initial access or privilege escalation stage of an intrusion, allowing attackers to pivot identities. Check whether your platform enforces secret revocation during ownership transfers. Ensure that credential delegation requires explicit consent from the new owner. Verify that token scopes are strictly enforced regardless of identity changes.

WHAT TO DO

Background: Privilege escalation vulnerabilities

Remove local administrator rights from daily users and enforce strict application whitelisting. These two steps block the majority of local privilege escalation attempts. Disable unused services and update dependencies to close known pathways that attackers use to gain higher system access.

Read the full guide: Stop Privilege Escalation: 5 Actions to Block Local Attacks

What to do and how to stay safe

  • Advisories bridge the gap between raw vulnerability data and business risk, enabling informed patch prioritization.
  • Ignoring advisories leads to technical debt accumulation, where minor issues compound into complex, unpatchable system failures.
  • Structured advisory workflows reduce mean time to remediate by eliminating guesswork and focusing efforts on high-impact threats.

Security advisories provide the technical context necessary to prioritize patches and mitigate risks effectively. Review advisories daily and map them to your specific assets to focus remediation efforts where they matter most.

Step-by-step guide: How Security Advisories Drive Patch Decisions and Reduce Risk

General security guidance from the Shell Bulletin newsroom. It is not confirmed advice from the organisations named in this story.

Sources

  1. CVE Program
  2. BleepingComputer
  3. Cyber Security News
  4. The Hacker News

Related stories

Secure UEFI Firmware to Stop BlackX Bootkit from Bypassing Secure Boot

Threat actors used a revived bootkit to bypass Secure Boot on diplomatic computers in Central Asia, gaining persistent kernel-level access.