25 Minutes to Admin Access: How an AI Agent Found a Live Baseten GitHub Token

The team at Strix, which builds an autonomous “hacker” AI agent, was planning to use the inference service Baseten (a company valued at $13 billion). Before handing their code and models over to a third-party service, the developers decided out of habit to stress-test it — and pointed their own tool at the domain *.baseten.co without any credentials or source code. Roughly 25 minutes later, the agent came back with a working GitHub token granting admin rights to Baseten's internal repositories.

How it was done

The agent started with reconnaissance: it enumerated hosts, examined certificate transparency logs and mapped out the attack surface. In the end it stumbled onto a Harbor container registry at gcp-us-east4-zlw.registry.baseten.co. One of the registry's projects turned out to be public — without authorization you could list the repositories, obtain an anonymous pull token and download the baseten/baseten-app image.

Rather than simply reporting the open registry, the agent downloaded the image and looked inside. A pair of AWS keys it found turned out to be invalid, but then, in the image metadata — in the history[].created_by field, where Docker stores the build history — it uncovered a classic GitHub personal access token. It had been passed as a build argument (ARG GITHUB_TOKEN) and ended up in the image history in full.

The scope of access

The build step was dated March 3, 2023, but the token still worked when it was found in July 2026 — more than three years later. A check showed that the basetenbot account had admin and write rights to the main product repository, to the GitOps repository that manages the clusters, and to the Homebrew tap through which the CLI reaches developers' machines. On top of that, it had read and write access to private repositories, including a directory with subfolders named after clients.

The authors stress that they did not clone the client repository and changed nothing: once they had gathered enough evidence, they immediately wrote a vulnerability disclosure email.

Baseten's response

The text reserves special praise for Baseten's security team. The very next day after being notified (July 13), they made the Harbor project private, confirmed the severity of the issue and revoked the token, and also asked that the downloaded images be deleted. As a thank-you for the find, they sent over T-shirts and hoodies.

Takeaway

The mistake is a common one: the token was passed as a build argument in order to pull in private dependencies, and Docker recorded its value in the history. The right approach is BuildKit secret mounts, restricting the token's permissions, setting expiration dates and mandatorily revoking old tokens. Changing the Dockerfile won't help an image that someone has already downloaded. The article's main lesson: inspect not only an image's files but also its build history, including old tags and forgotten registries.

Source: Hacker News