We got admin access to Baseten’s production GitHub in 25 minutes

We got admin access to Baseten's production GitHub in 25 minutes. We ended up with admin access to Baseten GitHub reposAlex SchapiroWe were about to trust Baseten with our own and our customers’ data.

What happened

About 25 minutes later, it had a live GitHub token with repository-level admin rights on internal Baseten repos. 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. Then it checked the individual repository permissions, again using read-only requests: RepositoryAccessbasetenlabs/b***admin: true, push: truebasetenlabs/f***admin: true, push: truebasetenlabs/h***admin: true, push: truebasetenlabs/r***Private, read/writebasetenlabs/b***Private, read/writebasetenlabs/t***Private, read/writebasetenlabs/b***Private, read/write This is an insane amount of access to leave in a publicly downloadable image.

And there it was: a classic GitHub personal access token, sitting in history[]. created_by. The token in the Docker build history, followed by GitHub identifying it as basetenbot. GitHub returned X-OAuth-Scopes: repo, and the account belonged to basetenlabs.

The wider picture

GitHub returned repo scope for basetenbot and listed basetenlabs as its organization. Still, this token from a 2023 build had admin access to their product and deployment repos when we found it. If an agent can find a live admin token in an old image in 25 minutes, you want yours to find it first. September 1st, 2026We wanted to use Baseten for inference. We were exploring our options, and Baseten is one of the obvious choices.

So. . . we pointed Strix at *. baseten. co and let it run without credentials or source code. But before we get into the details, let's give some kudos to Baseten's security team. Many times the most severe vulnerability on your infra may be on a service on a subdomain you forgot about (which is why we always recommend black box testing alongside testing with code access)!

What has been reported

Eventually, it found a Harbor registry at gcp-us-east4-zlw. registry. baseten. co. That included an image called baseten/baseten-app. The chain is what matters: enumerate public projects, read artifact metadata, mint an anonymous service/token scoped to repository:baseten/baseten-app:pull, pull the manifest, then fetch the blob through a signed storage redirect. The first promising hit was a pair of AWS keys in baseten/baseten-app. In this case, it contained a RUN command with the value of GITHUB_TOKEN expanded directly into it.

Strix used the token for a read-only GET /user request to GitHub and… VOILÀ. This was an old build credential that still had all of that access when we tested it in July 2026. A build needed to fetch private dependencies from GitHub, so somebody passed a token in as a build argument.

What happens next

The relevant pattern looked like this: 1ARG GITHUB_TOKEN2RUN GITHUB_TOKEN=${GITHUB_TOKEN} bash -c '\3 if [[ "${GITHUB_TOKEN}"! = "" ]]; then \4 git config –global –add \5 url. "https://${GITHUB_TOKEN}@github. com/". insteadOf "git@github. com:"; \6 fi' I can see how someone ends up writing this. What Strix did on its own Baseten has a responsive security team and already uses AI security tooling. It found a registry, checked whether it could actually pull an image, tested a credential and found it was dead, found another credential in the build history, and checked what that one could access.

It worked through the whole thing autonomously in about 25 minutes. The timeline was: July 13, 11:10 PM: I reported the live basetenbot token, the public Harbor project, and the repository permissions. July 14, morning: Baseten made the Harbor project private.