A security vendor evaluating Baseten as an inference provider pointed an autonomous scanning agent at the company's domains, with no credentials and no source code, and had a working GitHub token with admin rights on internal repositories about 25 minutes later. Strix published the disclosure on September 1, seven weeks after Baseten fixed it.
Key takeaways
- The credential was written into a container image's build history on March 3, 2023 and still authenticated when tested in July 2026.
- It carried repo scope with admin and push rights on Baseten's main product repository, the GitOps repository driving its clusters, and its Homebrew tap.
- Baseten's security team made the registry private and rotated the token within roughly 17 hours of the report.
How a scan got there
The run started with ordinary reconnaissance - host enumeration and certificate log inspection - which surfaced a Harbor container registry on a Baseten subdomain. Harbor groups images into projects, and one project on that instance was public. No token was needed to list its repositories, mint an anonymous pull scope, and download manifests and blobs, including an image named baseten/baseten-app.
An exposed registry alone is unremarkable; plenty of companies publish images deliberately. The question is what the image contains. A first find, a pair of AWS keys, turned out to be dead - a read-only identity call returned an invalid-token error. The agent kept going, pulled the layers, ran the open-source scanner TruffleHog, and then read the image config rather than just the filesystem.
The credential was in metadata, not a file
The token sat in the created_by field of the build history, a record of the command that produced each layer. The step in question had expanded a GITHUB_TOKEN build argument directly into a RUN line so the build could fetch private dependencies over Git. Docker stores that history in the image config, which downloads alongside the image itself.
This is the detail worth carrying away: deleting a credential file from a layer does nothing if the build history still holds a copy. The pattern compounds when a build also writes an authenticated remote URL into a global Git config, leaving a second copy behind.
A read-only request to GitHub returned 200 for an account named basetenbot, with repo scope and membership in the basetenlabs organization. Per-repository checks came back with admin and push on three repositories, plus read and write access to other private ones including customer-specific repos. Strix says it stopped there - no clones, no pushes, no configuration changes - and sent the disclosure email.
The response was fast
The timeline in the writeup is unusually tight for a vendor report. Strix filed at 11:10 PM on July 13. By the following morning the Harbor project was private, though the token itself was still live. At 4:34 PM on July 14 Baseten confirmed the issue as critical, said the token had been rotated, and asked the researchers to securely delete the pulled images, which they confirmed half an hour later. Remaining findings closed on July 17, and Baseten reviewed a draft of the post before publication.
Why old images keep doing this
Baseten, valued at $13 billion, is not an outlier in tooling or attention - the disclosure notes the company already runs AI security tooling of its own. The failure is that a build artifact from 2023 was never treated as part of the attack surface after the code around it moved on. Changing a Dockerfile does nothing about an image someone has already pulled, which is why revocation, not remediation, is the step that matters.
The recommended fix is a BuildKit secret mount so the credential never persists, followed by inspecting both layers and history. It is the same class of problem that keeps surfacing across the software supply chain, where a poisoned release of a crate with 245 million downloads stayed live for 86 minutes.
There is a second story here about who found it. An AI agent chained recon, registry enumeration, a dead-end credential, a metadata search, and permission mapping without being told to look for Harbor or for a token. That capability is not restricted to vendors doing diligence on Baseten before signing a contract.
FAQ
Was customer data accessed?
No. Strix states it verified the token's permissions using read-only GitHub requests and stopped there, without cloning the customer repositories it had access to, pushing code, or altering any configuration. It deleted the container images it had pulled at Baseten's request.
How was the token exposed if the files were clean?
It was recorded in the container image's build history rather than in a file. Docker saves the command that created each layer in the image config, and the build had interpolated the token value directly into a RUN command. That config downloads with the image.
How should build credentials be handled instead?
Use a BuildKit secret mount, which makes the credential available during the build without persisting it in the image or its metadata. Existing images should be audited for both layer contents and build history, and any credential found in a published image must be revoked rather than merely removed.
