Summary
- A vulnerability in Docker Hub allowed one authenticated user to push, pull, or delete container images as another user.
- The flaw was introduced through the feature that converts a personal Docker account into an organisation account.
- Docker patched the vulnerability on 30 September 2024 and published a security advisory on 12 October 2024.
- Docker states it found no evidence of exploitation in the wild, though the flaw had been present for approximately two years.
- Organisations relying on Docker Hub for container image distribution should review image integrity and audit recent registry activity.
What happened
Docker has patched a critical vulnerability in Docker Hub that, for roughly two years, allowed an authenticated user to perform push, pull, or delete operations on container images held in another user’s account. The company published a security advisory on 12 October 2024, roughly two weeks after the fix was applied on 30 September.
Where the bug lived
The flaw resided in the account conversion feature — specifically the mechanism that transforms a personal Docker Hub account into an organisation account. Docker’s advisory identified this conversion workflow as the source of the privilege confusion that made cross-account image manipulation possible. Beyond that, the company has not publicly detailed the precise technical mechanism.
What an attacker could have done
The practical consequences of exploitation would have been significant for any organisation treating Docker Hub as a trusted distribution point. An attacker with a valid Docker Hub account could theoretically have pushed a tampered image into a target’s repository, replacing a legitimate image with a malicious one, or deleted images to disrupt operations. They could equally have pulled images that the owner intended to keep private. In a software supply chain context, image tampering is a particularly sensitive risk: a developer or automated pipeline pulling a backdoored image from what appears to be a trusted source would have little reason for suspicion.
No confirmed exploitation — but two years is a long window
Docker says it found no evidence that the vulnerability was exploited before it was patched. That is the best available news here, and it should not be dismissed. However, the absence of evidence is not the same as confirmed clean history, and security leaders should weigh the two-year exposure window accordingly. Registry audit logs, where they exist, may not have surfaced anomalous cross-account activity unless someone was actively looking for it.
Disclosure and patch timeline
The vulnerability was remediated on 30 September 2024. Docker’s formal advisory followed on 12 October. The company has not publicly named a CVE identifier or credited an external researcher, and the source material does not indicate how the flaw was originally discovered.
Why it matters
Docker Hub is among the most widely used container registries globally, and many organisations consume public or shared images as part of automated CI/CD pipelines with limited runtime verification. A vulnerability that allows authenticated cross-account image manipulation strikes at the integrity of the software supply chain at a foundational level. Even where Docker Hub is used alongside a private registry, teams often pull upstream base images directly from Hub. CISOs should treat this as a prompt to review image provenance controls, ensure content trust or digest pinning is in use for critical images, and confirm that pipeline security posture does not rely solely on the assumption that a named repository was untouched.
What to do now
- Review Docker Hub registry audit logs for any unexpected push, pull, or delete activity over the past two years, particularly on repositories holding production or base images.
- Verify the integrity of container images in active use by checking image digests against known-good values where records exist.
- Confirm whether your pipelines pin images by digest rather than mutable tags, which reduces exposure to image substitution attacks.
- Evaluate whether Docker Content Trust or an equivalent signing and verification mechanism is enabled for critical image repositories.
- Remind engineering teams of Docker’s patch and advisory so they can raise any concerns about repository activity they may have noticed but not reported.
