A Docker Hub account conversion let one user's access token act as another user

Docker's side of this reaches us through one person. tmatens, who maintains the compose-lint linter, wrote up the notices on dev.to, and Docker's statement that it had seen no sign of exploitation is as tmatens relays it ^[22].

The two copies of the notice carried different weight. tmatens skimmed the one addressed to the organization owner, which said there was no action to take, and moved on. On a closer read, the user account was the one flagged ^[5]. The post describes the October 5 deactivation as planned and does not report whether it ran ^[4].

The check works because of where the signature comes from. Every compose-lint image is signed with cosign in keyless mode, using GitHub Actions' OIDC identity, and the certificate records the workflow and tag that produced the image, such as publish.yml@refs/tags/v0.34.0 ^[6]. Anyone holding Docker Hub push rights could still push an image. According to tmatens, that person could not produce the matching signature without running the workflow in the repo on a release tag ^[7]. tmatens wrote: "That meant I didn't have to take Docker's word for it." ^[8]

A valid signature alone proves little, since anyone can sign an image ^[9]. The verify command pins both ends. `--certificate-identity-regexp` matches only the publish and publish-channel workflows on a vX.Y.Z tag in tmatens/compose-lint, and `--certificate-oidc-issuer` is set to https://token.actions.githubusercontent.com ^[10]. The regexp lists two workflows because release 0.3.4 was republished by a different one ^[11]. All 42 images passed ^[12].

The loop fetches tags with one request at page_size=100 ^[18]. That covers 42 tags. It would not reach tags past the first page of a larger repo ^[20].

Signatures answer a narrow question: what does the tag point to now. A tag moved to a bad image and moved back would verify afterward ^[13]. So tmatens also checked each tag's last_pushed time, taken from the Docker Hub API, against the release runs. Every push lined up, and the tag list matched the releases with nothing extra and nothing missing ^[14]. A push from outside the release workflow would leave a timestamp with no run behind it, and moving a tag back is a push too.

The audit also turned up a hole in the pipeline. Right after pushing, the release workflow signed whatever the tag referenced. During the seconds between the push and the signature, anyone with write access to the registry could have repointed the tag and gotten the workflow to sign their image ^[16]. A signature from that workflow would then have vouched for an image it never built. The workflow now confirms that the tag resolves to exactly the image the build pushed, and halts before signing on a mismatch ^[17].

Then came the rotation. tmatens replaced the flagged tokens and split them so each job holds only the one it needs: read-only for nightly scans, push for releases, and a separate one for the Docker Hub description ^[15].