Autonomous agent pulled a live admin GitHub token from Baseten Docker layers in 25 minutes

What happened

An autonomous security agent needed 25 minutes to find live administrative credentials inside the public container infrastructure of Baseten, a machine-learning infrastructure company valued at around $13 billion. The account comes from a post on dev.to, which describes how the agent, named Strix, was pointed at Baseten's subdomains ahead of a possible vendor evaluation.

By the end of those 25 minutes, the agent held a GitHub personal access token belonging to a bot account, with administrative and push access to three core repositories — among them a GitOps repository used for cluster deployments — plus read/write access to private, customer-specific code. According to dev.to, no phishing and no zero-day were involved, and no human typed a command after the initial instruction.

The chain, step by step

The post lays out the sequence:

• Certificate transparency logs exposed a publicly reachable Harbor container registry at gcp-us-east4-zlw.registry.baseten.co.
• The registry allowed anonymous access: projects could be listed and anonymous tokens issued without logging in, and several projects were marked public.
• The agent pulled the baseten/baseten-app image, fetched its manifest and began walking the image layers.
• Running TruffleHog over the layers, it also inspected the image's build-history metadata — the recorded command line of every RUN instruction — rather than the filesystem.
• That history contained a GITHUB_TOKEN value inside a RUN command from a build dated March 3, 2023. Roughly three and a half years later, it still worked.
• A single call to GitHub's user endpoint confirmed the token belonged to basetenbot, carried classic repo scope, and had no expiration set.

How the secret got there

The underlying mistake, per the post, is a Dockerfile pattern where a token is passed as a build argument (ARG GITHUB_TOKEN) and then interpolated into a git clone command. ARG values are written into the image's build history in plaintext permanently, even when the cloned repository is deleted in a later instruction. The long-standing fix, available since Docker 18.09, is RUN --mount=type=secret, which exposes a secret only within a single build step and never records it in a layer.

The author's sharper argument is that the registry misconfiguration is merely how the token was found, not why it was dangerous. The real failure was a non-expiring, repo-scoped classic personal access token attached to a bot account and left unrotated for more than three years. GitHub has offered fine-grained tokens with expiration since 2022, and the post contends that classic PATs on service accounts are a policy failure regardless of how the leak happens.

Baseten's response

The finding was reported on July 13 at 11:10 PM, according to the post. The Harbor project was switched to private the following morning, and the token was rotated by 4:34 PM the same day — a same-day remediation the author describes as faster than most enterprises manage for a scheduled patch. Baseten also sent the researchers shirts and sweatshirts, which prompted a Hacker News debate over whether merchandise is adequate recognition for a critical finding at a $13 billion company, or whether undervaluing researchers pushes the next discoverer toward selling the find instead. The post separates that argument from the technical outcome, noting the disclosure was handled cleanly on both sides.

Why it matters

The vulnerability class here is old and well documented. What changed is the cost of finding it. The dev.to author points out that reconnaissance and credential hunting which once took a competent pentester a day of manual work took an unattended agent 25 minutes — and the same agent can be aimed at a thousand domains overnight.

That shifts the practical threat model: the population of parties capable of locating a forgotten 2023 build argument has grown from a handful of security researchers to anyone who runs an off-the-shelf agent against a company's subdomains. The follow-up checklist is unglamorous but immediate: scan Dockerfiles for build arguments named like secrets, audit bot-account token scopes and expiry dates, and verify that container registries genuinely require authentication.