We wanted to use Baseten for inference. We ended up with admin access to Baseten GitHub repos

September 1st, 2026

Alex Schapiro

We were about to trust Baseten with our own and our customers’ data. So to be safe, we ran Strix to ensure they were secure first. About 25 minutes later, it had a live GitHub token with repository-level admin rights on internal Baseten repos.

We build Strix, an autonomous hacking agent, which of course means we need (cheap and fast) inference. We were exploring our options, and Baseten is one of the obvious choices. It’s a great product, they’re valued at $13 billion, and a lot of serious companies depend on them.

But… we’re a security company. Before we give a third party our data, models, or code, we scan them. We would much rather find a problem and help get it fixed before we start depending on that service (we do this with almost all of our vendors and have a high rate of finding serious issues).

So… we pointed Strix at *.baseten.co and let it run without credentials or source code.

It came back with an active GitHub personal access token for basetenbot. That token had admin and push access to Baseten’s main product repo, the GitOps repo that drives their clusters, and their Homebrew tap, plus read/write access to other private repositories including specific repos per customers.

The image build dated to March 2023, and the token still worked when we found it in July 2026.

Baseten’s security team confirmed the issue as critical, locked down the registry project, and rotated the token by the next afternoon. They were professional and very quick to deal with it.

How Strix actually found it

Strix enumerated hosts, looked through certificate logs, mapped the full surface. Eventually, it found a Harbor registry at gcp-us-east4-zlw.registry.baseten.co.

Harbor stores container images and groups repositories into projects. One of these projects was public. Without any token or auth, Strix could list repositories, obtain anonymous pull tokens, and download the actual image manifests and blobs. That included an image called baseten/baseten-app.

Strix pulled an image and ran TruffleHog, and inspected the image config directly. And there it was: a classic GitHub personal access token, sitting in history[].created_by.

Strix used the token for a read-only GET /user request to GitHub and got 200, with the account name basetenbot.

Repository permissions

Repository	Access
basetenlabs/b***	admin: true, push: true
basetenlabs/f***	admin: true, push: true
basetenlabs/h***	admin: true, push: true
Additional private repos	read/write

Root cause

A build needed to fetch private dependencies from GitHub, so somebody passed a token in as a build argument. Docker recorded that build argument in the image’s metadata and history. In this case, it recorded the actual token value. Docker explicitly warns about this.

The build history was timestamped March 3, 2023. This was an old build credential that still had all of that access when tested in July 2026.

Disclosure timeline

• July 13, 11:10 PM: Reported the live basetenbot token, the public Harbor project, and the repository permissions.
• July 14, morning: Baseten made the Harbor project private.
• July 14, 4:34 PM: Baseten Security confirmed the issue as critical and rotated the token.
• July 14, 5:05 PM: Confirmed deletion of pulled images.
• July 17: Baseten closed out the remaining findings.
• September: Public disclosure planned.