Code & CI · Secret guide

Leaked Docker Hub Access Token: what to do in the first hour

Critical severityDetected onlyLast verified · 4 min read

A Docker Hub access token is what your CI pipeline or laptop uses to log in without a password. Depending on its permission level, it can pull private images and, more worrying, push new ones to your repositories. Anyone who can overwrite a tag that your servers or customers pull is in a position to run their code on your systems. Revoke the token, then verify that what you published is still what you built.

Check your GitHub account for leaked secrets — free

Provider
Docker Hub
Severity
Critical
Impact
Source code and build access
Checked live by LeakWatch
No

What a Docker Hub access token looks like

There are two kinds, told apart by the prefix:

dckr_pat_…XXXX   personal access token (masked)
dckr_oat_…XXXX   organization access token (masked)

A personal access token belongs to a user account and carries that user’s access to repositories. An organization access token belongs to an organization and is managed by its owners, which is the safer choice for CI because it does not depend on one person’s account. Both are used in place of a password with docker login.

Not the same secret: your Docker Hub password is a different credential, and so is a registry credential for another registry such as GitHub’s or a cloud provider’s. Container images themselves can also contain secrets, but that is a different problem from a leaked login token.

How Docker Hub access tokens get leaked

  • ~/.docker/config.json. After docker login, the file stores an encoded credential. Copying a home directory or committing a dotfiles repository publishes it.
  • CI workflow files. A token written directly into a pipeline definition, or echoed in a build log with debug output turned on.
  • Dockerfiles and build arguments. A token passed as a --build-arg or ENV is saved in the image history, so pushing the image publishes it.
  • Compose files and Kubernetes manifests. A pull secret with the encoded credential committed next to the deployment.
  • Shared scripts and tutorials. A release script posted in an issue or blog with the login line left intact.

What to do in the first hour

  1. Delete the token. In Docker Hub open Account settings → Security → Personal access tokens, find the token, and delete it. For an organization token, ask an owner to delete it from the organization’s settings. Deleting is immediate: the next login or pull using it fails.
  2. Create a replacement with the narrowest permission. Use read-only access when the job only pulls images, and read-and-write only for the pipeline that publishes. Give the token a name that tells you where it is used.
  3. Check what was pushed. For each repository the token could write to, open the Tags tab and compare the last-pushed times with your own releases. A tag updated when nobody released anything is the red flag. Compare image digests with what your build system produced.
  4. Treat suspicious tags as hostile. If a tag changed, stop pulling it, rebuild from source, and push a clean image under a new tag. Tell anyone who runs your public images, since they are the ones at risk.
  5. Check settings and webhooks. Review the repository webhooks, collaborators, and automated build settings for entries you do not recognize.

Not sure what else leaked? Run a free scan.

  1. Rotate credentials baked into images. If the token was in a Dockerfile or build argument, assume everything stored in that image history is exposed too.
  2. Then clean the repository: remove the value and rewrite history if you want to. See I accidentally pushed an API key to GitHub.

Not sure what else leaked? Run a free scan.

Revoke it at Docker Hub

Sign in to Docker Hub, open your account menu, then Account settings and the Security section. The Personal access tokens list shows each token with its description, permission level and last-used date. Use the row’s delete action to remove the exposed token. Organization access tokens are not in a user’s own list; an organization owner manages them from that organization’s settings. After deleting, run docker logout and log in again with the new token on any machine that used the old one.

How LeakWatch detects it

The rule is called Docker Hub Personal Access Token. It recognizes both prefixes, dckr_pat_ for personal tokens and dckr_oat_ for organization tokens, followed by the expected body length, so no surrounding keyword is required. LeakWatch detects this format but does not check it live: it can tell you the token is exposed, not whether it still works. Assume it does until you have revoked it.

LeakWatch detects this format but does not check it live: it can tell you the key is exposed, not whether it still works. Assume it does until you have revoked it.

FAQ

My token was read-only. Do I still need to act?

Yes. A read-only token can still pull your private images, which may contain source code, configuration and embedded secrets. Revoke it and review what those images contain.

How do I know if an image was tampered with?

Compare its digest with the one your build produced, and look at the push time in the Tags tab. If you sign images or keep build provenance, verify those as well. When in doubt, rebuild and publish under a new tag.

Does deleting the token log me out everywhere?

It stops that token only. Your password and other tokens remain valid, so rotate the password too if it may have been exposed along with the token.

Get alerted next time a secret leaks — create a free account

LeakWatch is not affiliated with Docker Hub.