Container Registry Tokens and Digest Pinning: How to Verify Image Provenance Beyond the Tag

Ask ten developers how they know the image running in production is the one they tested, and most will point at a tag. api:1.4.2 feels like a fixed address. It isn’t. A tag is a pointer, and any principal with push rights to the repository can move it. The useful question is not whether a tag looks trustworthy. It is what you actually trust at the moment you pull, and the answer runs through digests, signatures and, more than most teams expect, the tokens that can write to your registry in the first place.

Why now: On October 12, 2026, Docker published its advisory for CVE-2026-105445, a flaw in how Docker Hub handled account-to-organization conversions. Converting an account reassigned its personal access tokens to the new owner by changing an owner record, without rotating the secret. Docker says the exposure ran from August 26, 2024 to September 30, 2026, and reports no evidence of exploitation. The CVE is the news. The mechanism is the lesson.

Table of contents

• Tags are pointers, not contents
• What the Docker Hub flaw actually did
• Did you know
• Token hygiene: the part that is yours
• Pinning by digest, step by step
• Tag, digest or signed digest: what each one trusts
• Where digest checks still fail
• The lookback: which digests did you pull?
• What the advisory leaves out
• Sources

Tags are pointers, not contents

Every image in a registry is stored as a manifest, and every manifest has a digest, a SHA-256 hash of its content. A tag is simply a human-readable name that points at one digest. Push a new build under the same tag and the pointer moves. The old digest stays in the registry, untouched, until something removes it.

Think of a tag as the label on a shelf and the digest as the barcode printed on the box. Anyone with a marker can change the label. The barcode doesn’t change, which makes it the only part of the package a verifier should believe.

Most of us know this and still write FROM node:latest somewhere. Everyone has a :latest they swear they’ll pin next sprint, and that sprint has apparently become a permanent condition.

What the Docker Hub flaw actually did

The chain is short, and every step uses a documented feature:

1. An attacker creates a Docker Hub account and generates a personal access token (PAT). The attacker keeps the secret.
2. The attacker converts that account into an organization and names a victim as the owner.
3. Conversion moved the token’s owner record to the victim. The secret was not rotated, and the victim was not asked.
4. The attacker authenticates with the retained secret, and the registry treats the request as the victim, within the token’s scope.

Scope matters more than the headline. Within it, the attacker could pull, push or delete images in the target’s repositories and in organizations the target could access. Docker says the web UI, password, email and two-factor authentication were out of reach, so this was not a full account takeover. It was registry write authority, which is exactly what a deployment pipeline trusts.

Docker’s review is the most useful number in the advisory. It examined about 304,000 pushes made with transferred tokens. Every one landed in the converting organization’s own repositories or in the new owner’s own repositories. Static analysis of the highest-risk public images found no malware, cryptominers, command-and-control, credential harvesting, persistence or tampering. Docker’s own infrastructure was not affected.

Then comes the caveat that matters most. Docker’s registry logs show when a token was used, not that it existed. A transferred token nobody touched leaves no trace, so Docker did not rely on detection. It treated every transferred PAT in the window as potentially exposed. A clean log is weaker evidence than it looks.

Did you know

• The window was roughly 25 months long, from August 26, 2024 to September 30, 2026. Two researchers, Peter Molnar and Krisztian Hozak of mptrdev.com, reported it on the last day, and Docker shipped a fix the same afternoon, less than four hours later.
• Docker’s PAT documentation says a token’s secret is shown once and cannot be retrieved later. The secret is the credential. The owner field is a label attached to it, which makes it strange that the label could be moved without anyone’s consent.
• New personal access tokens default to no expiration, and their default permission is Repo Public Read-only. Expiration is optional: 30 days, 90 days, or a custom date up to one year out.

Token hygiene: the part that is yours

Docker’s remediation list is short. Review your PATs under account settings, revoke any you don’t recognize or no longer use, and move organization automation to organization access tokens (OATs). Docker says OATs are not tied to individual user accounts, which is the right instinct. I would start with a sharper question than the advisory asks: which of your tokens never expire, and which of them can still write?

Here is the audit I would run, in order. List the tokens for every account and organization your CI touches. For each one, name the pipeline or person that uses it. If you can’t name one, revoke it and see who complains. Then cut scope. A pull-only job should never hold push rights, and a publishing job should push only to the repositories it publishes. Finally, set expirations. Thirty days is a nuisance for a human and a sensible default for a robot, and a one-year token is still a year.

The trade-off is real. OATs solve the “whose laptop is this on?” problem, but they are still long-lived secrets, and rotating them is your job, not the registry’s. Keep them in your CI’s secret store. Never bake them into a Dockerfile or an image layer, where anyone who pulls the image can read them.

Pinning by digest, step by step

Here is the workflow I would use, with an example repository at registry.example.com/team/api.

Capture the digest at push time. A push ends with a line of the form digest: sha256: followed by a hex string. Treat that value as a build artifact. Don’t re-read the tag later, because two pipeline steps reading the same tag can see two different images.

docker push registry.example.com/team/api:1.4.2

Sign the digest, not the tag. A signature over a tag is a signature over a pointer that can move. Sign the immutable identifier.

cosign sign --key cosign.key registry.example.com/team/api@sha256:<digest>

Verify before anything deploys. This is the gate. If verification fails, the pipeline stops and nothing reaches the cluster.

cosign verify --key cosign.pub registry.example.com/team/api@sha256:<digest>

If your CI signs keylessly, replace the key with --certificate-identity set to the exact workflow allowed to sign, plus --certificate-oidc-issuer naming the issuer your CI uses. Resist the regular expression that matches everything. A signature without an identity check tells you that somebody signed these bytes. It does not tell you who.

Deploy by digest. In your Kubernetes manifest or Compose file, the image line should carry the digest.

image: registry.example.com/team/api@sha256:<digest>

Consider a pipeline that pulled api:latest on a Tuesday. On Thursday it can pull a different manifest without a single line of the Dockerfile changing. Pin the digest, and the Thursday pull either returns the exact bytes you tested or fails. The failure is the feature. Update bots like Renovate exist because everyone got tired of hand-editing hashes. The trade is a little more churn in exchange for a pull that cannot drift.

Check flag names against the Cosign documentation for the version you run before pasting them into production.

Tag, digest or signed digest: what each one trusts

Approach	What it trusts	If the tag moves	What it still misses
Tag, api:1.4.2	Whoever last wrote the tag	Your next pull changes silently	Who moved it, and what changed
Digest, api@sha256:…	The exact bytes you tested	Nothing: same bytes, or the pull fails	Who built those bytes, and whether they were bad when first pushed
Signed digest, identity-checked	A named signer bound to those bytes	Nothing: a different signer fails verification	A compromised signing key or CI identity

The rows get stronger in one direction, from what to who. A digest answers “is this the same blob I tested?” Only an identity-bound signature answers “who vouched for it?” Most teams stop at the middle row, because it stops silent drift. That is a fine place to stop, as long as you know you stopped.

Here is where the token flaw and the signing story meet, and it is the part I haven’t seen spelled out elsewhere. Signing and pulling use different credentials. A stolen token that can pull and push can overwrite a tag and can delete or replace artifacts in the repository. It cannot, by itself, produce a signature from the identity your verifier expects, because that identity lives in your CI’s signing setup or your private key, not in a registry token. A signed pipeline therefore fails closed when someone tampers. That is the right behavior. The catch is that a failed verification is a quiet event unless you alert on it, and many pipelines simply stop without anyone reading why.

This is my reasoning, not a sourced finding, and it holds only if your verifier checks an identity the attacker does not hold.

Where digest checks still fail

Three gaps remain.

First, a digest pins what you tested, not what is safe. If the first push was poisoned, you will pin the poison faithfully and deploy it with great consistency. Pinning is a stability guarantee. It is not a scan.

Second, identity is separate from integrity. A digest tells you the bytes haven’t changed. It says nothing about who produced them. That is why a checked-identity signature matters, and why a digest without a signature tells only half of the provenance story.

Third, flags in copy-pasted examples are often shortcuts. Some tutorials disable transparency-log checks so a demo runs quickly. Those are trade-offs to make on purpose, with a reason written down, not defaults to inherit.

Verification only protects you where something enforces it. A check in the pipeline blocks one deploy path. An admission policy in the cluster blocks all of them, including the one somebody added at 2 a.m.

The lookback: which digests did you pull?

Docker’s review covers Docker’s side of the registry. Yours is a separate job. If any repository or organization your CI touches was in the window, do three things. Pull the registry activity records for that period, if your provider keeps them. List every digest your deployments actually ran during it. Then compare those digests against the digests your build pipeline produced. A deployed digest with no matching build is not automatically an incident, but it is a question you need to answer before closing the ticket. Revoke and reissue any token whose ownership history you cannot account for.

What the advisory leaves out

Docker’s guidance is narrower than the problem. It tells you to review tokens, revoke unknown ones and move automation to OATs. It does not mention digests, signatures, or verifying images before deployment, which is where the damage would land if a tag moved under you.

Two other things bother me. Docker notified only the users it found exposed, so anyone who got no email was, by Docker’s account, not exposed. Your confidence rests on Docker’s scoping being right. And personal access tokens that default to no expiration turn every forgotten token into a long-lived risk. Neither is a scandal. Both are defaults that quietly decide your next incident.

If you take one thing from this, take the digest in your deploy file. The tag is for humans. The digest is for the machine about to run your code.

Sources

• Docker, “Docker Hub security advisory: CVE-2026-105445,” by Mark Lechner, October 12, 2026: https://www.docker.com/blog/docker-hub-security-advisory-cve-2026-105445/
• Docker Docs, converting an account to an organization: https://docs.docker.com/docker-hub/convert-account/
• Docker Docs, personal access tokens: https://docs.docker.com/security/access-tokens/personal-access-tokens/