A 2023 Docker build arg gave GitHub admin in 25 minutes

A Docker build arg from March 2023 handed a security firm admin access to a live production GitHub organization three years later. Strix published the disclosure this week: they were evaluating Baseten for inference, pointed their agent at the public surface first, and had an admin-scoped GitHub personal access token in 25 minutes. The token was not in the code. It was in the image's build history metadata, where almost nobody looks.

What actually happened

Strix's write-up lays out a short chain with no exploit in it.

A Harbor container registry was reachable without authentication. They enumerated repositories, pulled the baseten/baseten-app image, and read its layer metadata. A RUN instruction had expanded $GITHUB_TOKEN directly into the layer's created_by field — the command string Docker records for every step and hands back to anyone who runs docker history.

The build step ran March 3, 2023. The token still worked in July 2026. It belonged to a basetenbot account with the repo scope, which meant admin and push on three repositories — the main product repo, the GitOps cluster deployment repo, and a Homebrew tap — plus read/write on private repos including a directory of customer-named subdirectories.

Strix stopped there. No clone, no push, no config change. They reported it at 11:10 PM on July 13; the registry project was private by the next morning, and Baseten confirmed critical severity and rotated the token at 4:34 PM on July 14. On Hacker News, Baseten's Philip Kiely confirmed the remediation and said their logs show the vulnerability was never exploited and no customer data was exposed.

The root cause is a documented Docker behavior, not a bug. ARG GITHUB_TOKEN followed by a RUN that references it writes the expanded value into image metadata that ships with the image.

Why build-time secrets matter for your business

The exposure outlives the engineer who created it. Whoever passed that token in 2023 solved a real problem — a build needed private dependencies. The token then sat in a published artifact for three years, surviving every code review, every rotation policy, and a SOC 2 audit, because it was never in the source tree that any of those things examine.

Your scanners are looking in the wrong place. Secret scanning on commits, pre-commit hooks, and .gitignore discipline are all upstream of this. The leak is in a build output. If you publish images anywhere public — Docker Hub, GHCR, a Harbor instance someone spun up — run docker history --no-trunc against them and read what comes back.

Scope is the thing you control. A repo-scoped PAT on a bot account is a skeleton key. Fine-grained tokens, per-repo read-only where possible, and short expiry turn a three-year incident into a one-week one.

The fix is one directive. Use a BuildKit secret mount: RUN --mount=type=secret,id=gh reads the value at build time and never persists it to a layer. That is the whole change.

Sources: Strix disclosure, Baseten response on Hacker News.