Docker Hub EUVD-2026-98965

Exploitation requires an authenticated Docker Hub account and control of a personal access token, plus use of the specific account-to-organization conversion feature that reassigns the token to another user without rotating or revoking its secret (PR:L); impact is further bounded by the token's existing scopes and by which repositories the recipient user can access. It is not remote-unauthenticated: the attacker must already hold a valid Docker Hub credential and a PAT, and the abuse is constrained to the registry operations (pull/push/delete) permitted by that token. Because the flaw is in Docker Hub's hosted service, it affects the default Docker Hub configuration rather than a customer-tunable setting.

This is a genuine high-priority access-control flaw rather than an inflated high-CVSS issue. The vendor-assigned CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N, score 9.4) shows network-exploitable, low-complexity abuse requiring only a low-privilege authenticated Docker Hub account, with high confidentiality/integrity/availability impact on both the vulnerable system and subsequent systems (SC:H/SI:H/SA:H) - the subsequent-system impact is well justified because a token reassigned to a victim grants cross-account/organization registry access (image pull, push, and delete). The weakness class (CWE-266, Incorrect Privilege Assignment) is consistent with the description: a personal access token was reassigned to another user without rotating or revoking the secret, so the attacker retained a working credential that now authenticated AS the recipient. Signals are incomplete and should be stated plainly: no EPSS score, no CISA KEV listing, and no confirmed public exploit were provided in the input, so there is no evidence of active or at-scale exploitation. The 'ghostpat.com' reference appears to be a researcher write-up, not verified exploit code, so POC availability is unconfirmed. Because this is a server-side SaaS flaw in Docker Hub, remediation is vendor-controlled and the fix is not customer-deployable; the practical residual risk is any tokens that may have been mis-assigned before Docker's fix, which warrants token audit/rotation rather than patch deployment.

An authenticated Docker Hub user who controls a personal access token uses the account-to-organization conversion feature to reassign that unchanged token to another user, and because the secret is never rotated or revoked, the attacker keeps using it to authenticate to the registry as the victim. Operating within the token's scopes, the attacker can then pull, push, or delete images in repositories the victim can reach, including organization repositories. No confirmed public exploit was provided in the input; the referenced 'ghostpat.com' page appears to be a write-up rather than verified exploit code.