Strix finds a live GitHub admin token from 2023 in Baseten's Docker image

Strix, an autonomous pentesting agent, was tested against Baseten, an AI inference company valued at $13 billion, before its makers considered depending on Baseten as a vendor for their own data and models. They pointed Strix at the domain *.baseten.co with no credentials, no source code and no hints about what to look for. About 25 minutes later, it had a live GitHub personal access token carrying repository-level admin rights on Baseten's internal repositories.

Strix started with reconnaissance: enumerating hosts, checking certificate logs, and mapping the exposed surface. That turned up a Harbor container registry at gcp-us-east4-zlw.registry.baseten.co, one of whose projects was public. Without logging in, Strix could list repositories, pull anonymous tokens, and download image manifests and blobs, including one called baseten/baseten-app. Inside that image it first found a pair of AWS keys, but a read-only sts:GetCallerIdentity check returned InvalidClientTokenId: the keys were dead. Strix kept looking, ran the open-source scanner TruffleHog against the image's layers, and inspected the image's config directly. There, in a history[].created_by field that records how each build step was created, sat a GitHub personal access token: a RUN command had expanded the GITHUB_TOKEN environment variable directly into the build history.

Strix used the token for a read-only GET /user request to GitHub, which returned the account name basetenbot. Checking further, it found the token's OAuth scope was repo and that the account belonged to the basetenlabs organization. Checked repository by repository, the token had admin and push access to Baseten's main product repo, the GitOps repo that drives its clusters, and its Homebrew tap, plus read/write access to other private repositories, including some specific to individual customers. At that point, confident this was not a false positive, Strix's operators stopped: they did not clone the customer repo, push anything, or change any configuration, and wrote the disclosure email immediately.

The build step that embedded the token was timestamped March 3, 2023. Someone had needed to fetch a private dependency during the build, passed the token in as a build argument, and Docker recorded that argument, including its literal value, in the image's history. A related mistake, using git config --global to write an authenticated URL into Git's configuration, can leak a token the same way. Docker explicitly warns that build arguments can end up in an image's metadata this way. The token was still live more than three years later, when Strix found it in July 2026.

Baseten's security team responded quickly once notified. The authors reported the live token, the public Harbor project and the repository permissions on July 13 at 11:10 PM. By the next morning, Baseten had made the Harbor project private, though the token itself still worked. At 4:34 PM on July 14, Anton from Baseten Security confirmed the issue as critical, reported the project private and the token rotated, and asked the authors to securely delete the images they had pulled; the authors confirmed deletion and sent over two lower-severity findings from the same scan by 5:05 PM that day. Baseten closed out the remaining findings on July 17. In September, the authors told Baseten they planned to publish the finding and shared a draft of the post; as thanks, Baseten sent them T-shirts and sweatshirts. The post frames the episode as a warning: even a company with a responsive security team and its own AI security tooling can have a three-year-old build credential quietly holding admin rights, and the same autonomous techniques that found it in about 25 minutes are available to attackers too.

Key facts

Pointed at *.baseten.co with no credentials, source code or hints, the autonomous agent Strix found a live, admin-scoped GitHub token in about 25 minutes.
The token, for the GitHub account basetenbot in the basetenlabs organization, carried admin and push access to Baseten's main product repo, its GitOps repo, and its Homebrew tap, plus read/write access to other private repos including some specific to individual customers.
The token had been sitting since a build on March 3, 2023 in the config history of a public Docker image, baseten/baseten-app, hosted on Baseten's Harbor registry, and still worked when Strix found it in July 2026, more than three years later.
Baseten, an AI inference company valued at $13 billion, made the Harbor project private within a day of the July 13 report and had the token rotated by 4:34 PM the next day, per Baseten Security's Anton.
As thanks for the disclosure, Baseten sent the researchers T-shirts and sweatshirts; no monetary bounty is mentioned in the post.

Why it matters

The story is a clean demonstration of what an autonomous security agent can do without any inside help: no login, no source code, no hints, just a domain name, and about 25 minutes later it holds an admin-scoped credential to a $13 billion AI infrastructure vendor's core repositories. The vulnerability itself is mundane, a token baked into a container image's build history rather than its visible files, but that is exactly why it is dangerous: scanning an image's filesystem is not enough, since its build history is a separate place secrets hide, and this one had been sitting there since March 2023 while nobody looked. The piece explicitly frames the episode as a preview of what AI-powered attackers can now do at the same speed.

Who it affects

Baseten, directly, and through the leaked token's read/write access to per-customer repositories, an unspecified number of Baseten's own customers whose code sat in those repos. More broadly, it affects any team that builds Docker images with a token passed in as a build argument to fetch private dependencies, since Docker can record that argument, value included, in the image's own metadata and history even after the credential is removed from the visible files. Anyone running a Harbor or similar container registry with a public project is also implicated: Strix reached the image without logging in at all.

How to use it

The post's own checklist: find out what a container registry exposes without a login, including old tags and projects nobody remembers; read an image's build history with docker history --no-trunc, or pull the config blob and check its history[].created_by fields directly, not just the image's files; get secrets out of build arguments entirely and use a BuildKit secret mount with temporary authentication that does not persist into the image; and, having found a leftover token, check exactly what it can access rather than assuming it is harmless, then limit its scope and give it an expiry. Crucially, changing the Dockerfile does not retroactively fix images that have already been pulled, so an exposed credential still has to be revoked, not just avoided going forward.

How solid is it

This is a first-person account from the security firm that built Strix and found the bug, published on its own blog, so the framing naturally favors its own tool. But the technical claims are specific and checkable in kind: exact API responses (X-OAuth-Scopes: repo, a 200 from GET /user, InvalidClientTokenId on the dead AWS key), an exact registry hostname, an exact build date, and a disclosure timeline given to the minute with a named contact, Anton from Baseten Security, who confirmed the issue as critical on Baseten's side. That level of specific, checkable detail, plus the fact that Baseten's own security team corroborated the severity and fixed it, supports the account; there is no independent third-party confirmation, since this is the finder's own writeup.

Risks and caveats

The account comes entirely from the party with an interest in showcasing its own product's capability, and it was published in September about a finding first reported in July, after Baseten had already fixed it, which is a normal disclosure delay but still means the public sees only the finished, favorable version. The post does not say how many customer-specific repositories the token could reach, does not describe the two lower-severity findings it also reported, and does not say whether anyone other than Strix accessed the token during the more than three years it sat live. The only compensation mentioned is T-shirts and sweatshirts, not a monetary bounty; the post says nothing about a bounty program either way.

“This is an insane amount of access to leave in a publicly downloadable image.”

— the authors, on Strix's blog