DEV Community: Todd Matens

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

Todd Matens — Mon, 12 Oct 2026 23:48:20 +0000

A critical bug in Docker Hub's access controls meant some personal access tokens, including the ones I use to publish compose-lint, a security linter for Docker Compose files, could have been used by someone else. Not the email you want on a Friday afternoon.

I actually got two of them on Friday, October 2, about an hour apart. The one I happened to open first was addressed to me as the organization owner. It was pretty vague and said there was no action for me to take, so I skimmed it and moved on. The other one, sent to my user account, was titled "Action Requested." When I had a chance to read both more closely, I realized my user was the one flagged, and Docker was planning to force-deactivate my two CI tokens that Monday, October 5.

On September 30, an outside researcher had reported a flaw in Docker Hub's identity and access management. Under certain conditions around converting a personal account to an organization, one user could take on another user's capabilities through a personal access token, which means pushing or pulling images as them. Docker said they fixed it within about four hours and hadn't seen any sign of it being exploited.

At that point I knew I needed to rotate my tokens and check that my published images hadn't been touched.

Why I could check

I started compose-lint because I couldn't find a Compose linter that met my needs or that I was happy with, and I'd been looking for a chance to build something open source. I also wanted a project where I could build with complete freedom and put everything I know about security engineering into it, including the release pipeline.

So every compose-lint image is signed with cosign, keyless, using GitHub Actions' OIDC identity. The signing certificate records the workflow and tag that produced the image, something like publish.yml@refs/tags/v0.34.0. Someone with Docker Hub push access could push an image, but they couldn't produce that signature without running my workflow in my repo on a release tag.

That meant I didn't have to take Docker's word for it. I could go check.

What I checked

I verified every tag against my workflow identity. Checking that an image has a valid signature isn't enough on its own, since anyone can sign an image. You have to pin who signed it.

This is where I hit something I hadn't thought about. Most of my images were signed by publish.yml, but one older release, 0.3.4, was signed by a different workflow I'd used to republish it. Different workflow, different identity in the certificate. I could still verify everything, but it meant using a regexp that allowed both workflows instead of one exact identity. It works, it's just not as clean as I'd like. If you're setting this up, it's worth keeping signing in one workflow, or at least knowing every identity you've ever signed with.

for tag in $(curl -s "https://hub.docker.com/v2/repositories/composelint/compose-lint/tags?page_size=100" \
  | jq -r '.results[].name'); do
  cosign verify "docker.io/composelint/compose-lint:${tag}" \
    --certificate-identity-regexp '^https://github\.com/tmatens/compose-lint/\.github/workflows/(publish|publish-channel)\.yml@refs/tags/v[0-9]+\.[0-9]+\.[0-9]+$' \
    --certificate-oidc-issuer https://token.actions.githubusercontent.com \
    > /dev/null && echo "ok   ${tag}" || echo "FAIL ${tag}"
done

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

A 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. So I also pulled each tag's last_pushed time from the Docker Hub API and matched it against my release runs. Every push lined up with a real run. I also compared the full list of tags against my releases to make sure nothing extra had shown up and nothing was missing.

Everything came back clean. I rotated the tokens and split them up so each job only gets the one it needs: read-only for the nightly scans, push for releases, and a separate one for updating the Docker Hub description.

What I changed afterward

Going back through the pipeline, I found a couple of things I wanted to fix.

The release workflow signed whatever the tag pointed to right after pushing it. In the few seconds between push and sign, someone with write access to the registry could have moved the tag and gotten their image signed by my workflow. The window is small, but it's there. Now the workflow checks that the tag points to exactly what the build pushed, and stops before signing if it doesn't.

The verify step in CI was also using a loose regexp. It now checks the exact workflow with --certificate-identity "https://github.com/${GITHUB_WORKFLOW_REF}".

And signing doesn't help much if nobody verifies, so I added the command to the docs:

VERSION=0.34.0
cosign verify "docker.io/composelint/compose-lint:${VERSION}" \
  --certificate-identity "https://github.com/tmatens/compose-lint/.github/workflows/publish.yml@refs/tags/v${VERSION}" \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com

The docs cover how to verify compose-lint images in more detail, including the SBOM and VEX attestations.

If you maintain images and aren't signing yet

On GitHub Actions it's about twenty lines. The job needs id-token: write so cosign can get a short-lived certificate tied to your workflow, and you sign by digest, not by tag:

permissions:
  contents: read
  id-token: write

steps:
  - uses: sigstore/cosign-installer@<pinned-sha>
  # build and push, capturing the digest
  - run: cosign sign --yes "docker.io/your-org/your-image@${DIGEST}"

You can see the sign and verify steps in compose-lint's release workflow, and the rest of the project is on GitHub.

Twenty lines is the open source on GitHub version. At a bigger org, signing is the easy part. Managing keys, keeping private repo names out of public transparency logs, deciding which builds to trust, and actually enforcing verification at deploy time is where it gets hard.

For a small project, though, it's cheap. And the next time a vendor tells you there's no evidence of exploitation, you'll be able to check for yourself.

Personal project, personal views.

9 in 10 Docker Compose files skip the basic security flags

Todd Matens — Fri, 22 May 2026 22:48:21 +0000

Update, October 2026: this post covers the first edition of the study (6,444 files). The current edition covers 11,111 files with a tighter methodology, and some headline numbers have changed. Most notably, 99.2% of the files that actually lint now carry at least one finding. Read the current edition: State of Docker Compose Security

I created compose-lint, a security linter for Docker Compose files, and pointed it at 6,444 public docker-compose.yml and compose.yaml files from GitHub. (More on why below.)

Three things stood out:

91% of the files that parse have at least one security finding.
68% have at least one HIGH or CRITICAL finding.
The same three issues top every category I looked at, including the official vendor examples people are told to copy.

I don't read this as engineers being careless. It's about defaults. Docker Compose ships with the hardening switched off, almost nobody turns it on, and the examples people learn from don't either.

Why this exists

By day I lead a team of security engineers at a large financial institution, where Compose barely comes up. Production runs on Kubernetes and ECS, both with mature security tooling around them. At home in my lab, though, Compose is the right tool: quick, low-ceremony, enough to stand up a stack on a Saturday.

What bugged me was the asymmetry. Kubernetes and Terraform have a deep bench of scanners: Checkov, Trivy, kube-bench, Kubescape. Compose is an afterthought in most of them. The Compose-specific tools I found solved adjacent problems instead. Hadolint lints Dockerfiles, not Compose files. dclint checks Compose structure and style, not security.

What I wanted was simple: a zero-config, OWASP/CIS-grounded linter I could drop into CI and run against my own stacks. So I wrote one. Then I got curious whether the stuff I kept fixing in my own files showed up everywhere else.

It does. That's what this writeup is about, and I'm putting the tool out there in case it's useful to anyone who builds the way I do.

Personal project; the views here are my own, not my employer's.

Here's what I found.

How the corpus is built

I split the files into four tiers. A single "X% of Compose files do Y" number is misleading when it averages a polished Bitnami example against someone's half-finished homelab:

canonical (327 files) — official upstream examples: awesome-compose, Bitnami, Grafana, Vaultwarden. The stuff READMEs tell you to copy-paste.
popular (3,977) — repos with ≥50 stars and a recent Compose file. Production-adjacent code.
selfhosted (588) — app-store / template registries: CasaOS, runtipi, Dockge. Home-LAN threat model.
longtail (1,552) — a stratified sweep of GitHub code search. The median file in the wild.

Every file goes through the same rule set (compose-lint 0.7.0), and every rule is grounded in the OWASP Docker Security Cheat Sheet or the CIS Docker Benchmark. The full methodology, including what the study deliberately doesn't claim, is in the canonical report.

Finding 1: nobody flips the hardening flags

Three findings fire on roughly 90% of every file in the corpus:

Filesystem not read-only (read_only: true missing) — 91%
No capability restrictions (cap_drop: [ALL] missing) — 91%
Privilege escalation not blocked (no-new-privileges missing) — 90%

They're rated MEDIUM, not CRITICAL, because each one is a missing control rather than active misuse. That's also what makes them interesting. The Compose hardening triple is almost never set.

The fix takes about 30 seconds per service:

services:
  app:
    image: nginx:1.27@sha256:...   # pin a digest, not just a tag
    read_only: true                # CL-0007
    cap_drop: [ALL]                # CL-0006
    security_opt:
      - no-new-privileges:true     # CL-0003

Add a tmpfs: for whatever paths your app writes to and you've cleared the three most common findings in the corpus.

"Aren't these just optional config choices, not real vulnerabilities?" Mostly fair, and it's worth being exact about what a "finding" is here. The linter isn't claiming anything was exploited. It's flagging that a file leaves a recommended hardening control unset. Whether that matters is a judgment call that belongs to the org or the engineer, based on their context and risk tolerance. What the linter takes off your plate is the "did I even know this control existed?" part. read_only, cap_drop: [ALL], and no-new-privileges aren't my preferences about tidy YAML; they're named controls in the CIS Docker Benchmark and the OWASP Docker Security Cheat Sheet. A finding means the config diverges from that published baseline. Closing the gap or accepting it is your call.

Finding 2: even copy-paste vendor examples aren't clean

You'd expect the official examples to be the hardened ones. Being copied is their entire job. They're the cleanest tier in the corpus, and they still come in at 83%:

A few things jump out:

Self-hosted app-store templates: 100%. Every single one trips at least one rule. They're built for "works on your LAN in one click," which in practice means exposed ports, root users, and big host mounts.
Popular repos aren't better than the long tail. Stars don't buy hardening discipline.
Canonical examples are config demos, not hardening exemplars. People copy them into production anyway.

That last point is most of the story. The examples teach the unhardened shape, and the shape propagates.

A fair caveat here, especially if you're running a homelab: threat model matters. A single-user box behind a firewall and Tailscale is a different risk calculus than something exposed to the internet, and a finding is usually something to decide about rather than an emergency. Start with what actually bites. A mounted Docker socket is full host takeover whether or not you meant to expose it, so fix those first and treat the MEDIUM pile as gradual cleanup. It's why the CI gate defaults to fail-on: high.

Finding 3: ~10% of ordinary files don't even parse

This is the one I didn't expect. In the long-tail tier, 9.6% of files don't parse as a valid Compose file at all, against well under 1% everywhere else:

And it's almost never broken YAML. It's shape errors: people writing services as a dictionary of strings.

# What a lot of people write (does not parse):
services:
  nginx: nginx:1.27

# What Compose actually wants:
services:
  nginx:
    image: nginx:1.27

A file that doesn't parse with a real Compose engine was never deployed by one. So these are docs snippets, tutorial follow-alongs, half-finished first drafts. None of them are getting linted before they ship, and the parse-error rate is really a map of where unreviewed config piles up.

(If you're wondering: "long tail" here means the low-visibility mass of ordinary repos, not a statistical distribution tail.)

Why it's all MEDIUM-heavy

One more chart, because the severity mix surprises people:

Nearly four out of five findings are MEDIUM. That's the hardening-triple misses from Finding 1, which hit almost every file and are MEDIUM by design. CRITICAL findings are rarer but real: a mounted Docker socket, cap_add: ALL, a bind-mounted /. The Docker socket one alone, which is full host takeover, shows up on 6.4% of parsed files and 8% in the popular tier.

LOW is almost empty, and that's by construction. Only one of compose-lint's 21 rules is LOW (a healthcheck someone explicitly turned off), because the tool's whole scope is security misconfiguration, where the floor is MEDIUM. So read "0.0% LOW" as a fact about the tool, not as the small stuff being fine.

So why are all the flags off by default?

Because Docker optimizes for "it runs the first time." A writable filesystem, the full capability set, privilege escalation left on: that's the path of least surprise. Your container starts, your app works. Hardening is opt-in, and opting in means knowing the control exists, confirming your app still works without that capability or that write access, and adding a few lines per service.

And "knowing it exists" is the hard part. There's no single secure-Compose baseline to copy from. The controls are scattered across the Compose spec, the Docker run reference, the OWASP Docker Security Cheat Sheet, and the CIS benchmark. You'd have to already know that no-new-privileges is a thing, that cap_drop: [ALL] goes before a targeted cap_add, that read_only: true usually needs a tmpfs for whatever your app writes. Most people writing a Compose file aren't container-security specialists. They want their stack up. Expecting everyone to carry that whole surface in their head is how you end up with a 91% finding rate. A linter flips it around: you don't memorize anything, you fix the line it points at and read why.

And it compounds. The examples never opt in, so the next person copies the unhardened shape, ships it, and becomes the next example someone copies. The corpus is that loop at scale. None of it is exotic. It's the accumulated weight of a sensible default that nobody goes back to revisit.

What this is not

A few things I'm explicitly not claiming, because it's easy to over-read this:

It measures how common misconfigurations are, not whether they were exploited. A finding is divergence from hardening guidance, nothing more.
It's descriptive sampling, not statistical inference. No p-values, no population estimates.
It's GitHub-only and public-only. Private and enterprise Compose may look different.

The full "what this study does not claim" section in the report lays out every boundary.

Try it on your own files

compose-lint is MIT-licensed, zero-config, and depends only on PyYAML. A few ways to run it:

# one-off, locally
pipx install compose-lint && compose-lint docker-compose.yml

# or the published image (distroless, nonroot)
docker run --rm -v "$(pwd):/src" composelint/compose-lint

In CI, there's a GitHub Action:

# .github/workflows/compose-lint.yml
name: compose-lint
on: [pull_request]
jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: tmatens/compose-lint@v0.7.0
        with:
          pattern: "**/*compose*.y*ml"   # docker-compose.yml, compose.yaml, …
          fail-on: high

fail-on: high (the default) fails only on HIGH/CRITICAL, so you can adopt it without drowning in the MEDIUM backlog on day one, then tighten later. There's also a pre-commit hook, JSON and SARIF output (SARIF feeds GitHub Code Scanning), and compose-lint --explain CL-0007 to print any rule's rationale and fix.

For what it's worth on a tool you'd wire into CI: every rule cites OWASP, CIS, or Docker docs, the image is distroless and nonroot, and releases ship SLSA provenance and Sigstore attestations. Details are in the repo.

The full report has every table, the complete methodology, the per-rule breakdowns, and steps to reproduce it: State of Docker Compose Security

If you maintain a popular Compose example, I'd genuinely love a PR or an issue. Hardening the examples people copy is the highest-leverage fix there is.