Docker Hub's access token vulnerability: how signing let me verify my images

Description and use

Due to a Docker Hub IAM flaw, personal access tokens could impersonate users. The author verified all compose‑lint images with cosign, rotated tokens, and tightened the release workflow to prevent future tampering.

Problem

A critical bug in Docker Hub’s IAM allowed personal access tokens to impersonate other users, risking unauthorized image pushes and pulls.

Outcome

All 42 compose‑lint images verified to the correct CI run; no unauthorized changes detected. Tokens rotated and workflow hardened.

Workflow

• 1. Rotate compromised tokens and split permissions per job
• 2. Verify each image tag with cosign using a strict certificate‑identity regexp
• 3. Pull each tag’s last_pushed time from Docker Hub API and compare with release runs
• 4. Ensure no extra or missing tags exist
• 5. Update release workflow to check tag integrity before signing
• 6. Tighten CI verify step to use exact workflow identity
• 7. Add verification command to documentation

Evidence

All 42 images verified, and every one traced back to the CI run that built it.

Source

I could still verify everything, but it meant using a regexp that allowed both workflows instead of one exact identity.

Source

The signature check only tells you what a tag points to today, though. Someone could point a tag at a bad image, wait for people to pull it, then point it back, and everything would still verify afterward.

Source