You know that Docker layer you built in 2023 and forgot about? It's still running. And if you ever passed a secret through ARG, it's still readable — cleartext, no auth, indexed by anyone who knows to look.
That's the entire story of what happened to Baseten, an ML infra company valued around $13B. Strix, an autonomous pentest agent, pointed itself at *.baseten.co to kick the tires before a potential vendor evaluation. Twenty-five minutes later it had a GitHub personal access token with admin rights to Baseten's product repos, their GitOps cluster-deployment repo, and read/write on private customer code. No phishing. No zero-day. No human even typing commands after the first prompt.
Here's the full chain, because every step of it is a mistake you've probably made too.
Recon. Cert transparency logs turned up gcp-us-east4-zlw.registry.baseten.co — a Harbor container registry, publicly reachable.
Anonymous access. Harbor let you list projects and pull anonymous tokens without logging in. Several projects were public. This alone should have ended the story with "reported low-severity misconfiguration."
Image inspection. The agent pulled baseten/baseten-app, grabbed the manifest, and started walking the layers.
Credential hunting. It ran TruffleHog over the layers and — this is the part that matters — inspected the Docker image's history[].created_by metadata. Not the filesystem. The build history. Docker keeps a record of every RUN instruction's literal command line, forever, baked into the image, whether or not that layer's files ever ship.
The find. A GITHUB_TOKEN value, sitting in a RUN command from a build dated March 3, 2023. Three and a half years old. Still live.
Validation. One GET /user call to the GitHub API confirmed it. The token belonged to basetenbot, scoped to repo — full repository access, no expiration. Admin and push on three core repos. Read/write on customer-specific private repos.
Total elapsed time: 25 minutes. Total humans involved on the attacking side: zero, past the initial "go check this company out" prompt.
It's this pattern, still everywhere in 2026:
ARG GITHUB_TOKEN
RUN git clone https://${GITHUB_TOKEN}@github.com/basetenlabs/baseten-app.git
ARG values get baked into the image's build history as plaintext, permanently, even if you RUN rm -rf the cloned repo two lines later. The fix has existed since Docker 18.09 and everybody still gets this wrong:
RUN --mount=type=secret,id=github_token \
GITHUB_TOKEN=$(cat /run/secrets/github_token) \
git clone https://${GITHUB_TOKEN}@github.com/basetenlabs/baseten-app.git
--mount=type=secret never touches a layer. It's available only inside that one RUN step and vanishes after. If your Dockerfile has ARG anywhere near the word TOKEN, KEY, or SECRET, stop reading this and go check it right now. I'll wait.
Strip away the container registry angle and you're left with the actual root cause: a non-expiring GitHub PAT with repo scope, attached to a bot account, that nobody rotated for three and a half years. The Docker leak is how it got found. It wasn't how it became dangerous.
That's the part worth sitting with. Even if Baseten had locked the registry down perfectly, that token was a standing liability the entire time — one leaked CI log, one compromised laptop, one overly-permissive Slack integration away from the same outcome. repo-scoped classic PATs on service accounts are a policy failure independent of any one delivery mechanism. GitHub has had fine-grained tokens with expiration since 2022. If you're still minting classic PATs for bots, you're one forgotten build arg away from this exact writeup with your company's name on it.
Reported July 13, 11:10 PM. Harbor project locked to private the next morning. Token rotated by 4:34 PM the same day. That's a same-day full remediation on a critical finding, which is faster than most enterprises manage for a scheduled patch.
They sent the researchers t-shirts and sweatshirts. The HN thread had opinions about that — is merch adequate compensation for finding a critical vuln at a $13B company, or does underpaying legitimate researchers push the next person to sell the find instead? Fair question. But separate it from the technical postmortem: the engineering response was fast and the disclosure was handled like adults on both sides.
The interesting long-tail lesson isn't "Docker secrets are hard," everyone already half-knows that. It's the speed. An autonomous agent went from "here's a domain" to "here's an admin token with a scope map of what it can touch" in 25 minutes, with no human in the loop after the initial instruction. That used to be a day of manual recon and grep for a competent pentester. Now it's coffee-break work, and it scales horizontally — the same agent can point at a thousand domains overnight.
Which means the population of people who can find your 2023 build-arg leak just went from "a handful of security researchers who happen to check" to "anyone who runs an off-the-shelf agent against your subdomains." Your threat model needs to update accordingly, not because the vulnerability class is new, but because the discovery cost just collapsed.
Go check your Dockerfiles. Go check your bot accounts' PAT scopes and expiration dates. Go check if your container registry actually requires auth. None of this is exotic. All of it is still sitting in production somewhere, right now, in a layer nobody's looked at since 2023.