Baseten's GitHub Admin Token Sat Exposed in Docker for 3 Years

A security researcher spent 25 minutes probing Baseten's public infrastructure and came away with a GitHub token that had admin access to the company's core product repository, its deployment pipeline, and a private repo listing its actual customers by name. Baseten is a $13 billion AI inference platform that companies use to host and serve machine learning models in production, and the token that exposed all of this had been sitting live, unrevoked, since March 2023.

• A public container registry was the entry point. One Harbor project at a Baseten subdomain allowed anyone to list and pull Docker images with no login required.
• A GitHub token was baked into image build metadata. The credential, named basetenbot, had admin and push rights to Baseten's main product code, its GitOps pipeline, and its CLI distribution channel.
• It also reached a private repo listing Baseten's own customers. A directory named customers/ held a subfolder for each client company.
• The token was live for roughly three years and four months before anyone found it, and Baseten fixed the whole chain within about 17 hours of being told.

How did a security researcher find this in 25 minutes?

The finder was Strix, an autonomous AI pentesting agent built by a security firm called OmniSecure. Its write-up describes the process in blunt terms: it enumerated hosts tied to Baseten's domains, checked certificate transparency logs for subdomains nobody was advertising, and mapped what it found. That turned up a Harbor registry, a self-hosted Docker image store, sitting at gcp-us-east4-zlw.registry.baseten.co. Harbor projects can be set to public or private, and this one was public. Anyone could list every repository in it and pull the images down, no credentials needed.

RelatedGeoServer Zero-Day Exploited Hours After Disclosure

That alone isn't catastrophic. Plenty of companies publish public container images on purpose. What made it dangerous was what came bundled inside one specific image.

How does a token from 2023 end up baked into a Docker image?

Docker images remember more than developers expect. When a build step passes a secret as a build argument and that argument gets expanded directly inside a RUN command, Docker writes the resolved command, secret included, into the image's layer history. Anyone who can pull the image can run docker history or inspect the manifest and read it back in plain text. This isn't an exotic bug. It's one of the most common ways teams accidentally ship credentials, and it has burned companies going back to the early days of container adoption.

Strix traced the leak to a build of the baseten/baseten-app image from March 2023, where a GitHub personal access token belonging to a bot account called basetenbot got expanded into a build command instead of being pulled in through a secret mount. That image sat in the registry for years. Nobody rotated the token, and nobody noticed the registry serving it had drifted from private to public, or was set up that way from the start.

What could that token actually reach?

basetenbot wasn't a scoped, read-only key. It carried repository-level admin and push access to basetenlabs/baseten, the company's main product code, and to basetenlabs/flux-cd, the GitOps repo that controls what actually gets deployed to production infrastructure. Push access to a GitOps repo is a genuinely dangerous permission: whoever controls it can change what runs in a cluster without ever touching a server directly. The same token reached basetenlabs/homebrew-tap, which distributes Baseten's command-line tool to developers who trust that channel by default.

Then there was basetenlabs/fde, a private repo the token could also read and write. Listing its contents showed a top-level customers/ directory with a subfolder for what Strix describes as customer after customer, named individually. Strix's write-up doesn't say what was inside those subfolders beyond the directory structure itself, and neither Strix nor Baseten has published a count of how many customers were listed or confirmed whether any customer data beyond names was exposed.

1. Mar 2023basetenbot token gets baked into baseten-app image build history.
2. Jul 13, 11:10 PMStrix reports the live token and public Harbor exposure to Baseten.
3. Jul 14, morningBaseten makes the Harbor project private.
4. Jul 14, 4:34 PMBaseten's security team confirms critical severity and rotates the token.
5. Jul 14, 5:05 PMStrix confirms it has securely deleted the pulled images.
6. Jul 17Remaining findings from the engagement are resolved.
7. Sep 15Strix publishes the disclosure publicly, roughly two months after the fix.

Why did the fix take under a day, and is that normal?

It isn't, and that's worth saying plainly. Plenty of disclosed vulnerabilities sit unpatched for months while a vendor's security team triages, argues about severity, or simply doesn't respond. Baseten made the registry private the morning after the report and had the token rotated by mid-afternoon the same day, a turnaround of well under 24 hours for a finding that touched production code access, deployment control, and a customer list. Strix's write-up credits the team directly for that, and it's the kind of detail that matters more to a prospective enterprise customer than the vulnerability itself: everyone's infrastructure has gaps, but not everyone closes them the same day they're told.

RelatedWordPress Core RCE flaws exploited to plant webshells

What Baseten hasn't done is put out a public statement of its own. Everything about the company's side of this comes secondhand, through Strix's post. There's no confirmed count of affected customers, no CVSS score attached, and reportedly no bounty payout beyond, in Strix's words, some T-shirts and sweatshirts.

What does this mean for AI infra platforms holding enterprise trust?

Baseten's pitch to customers is that they can hand over model hosting and stop worrying about the infrastructure underneath it. That pitch rests entirely on trust, and trust is exactly what a leaked admin token undermines, even when the actual damage turns out to be contained. The company was last valued at $13 billion on the strength of enterprises betting their inference workloads on it. A story like this one doesn't move that valuation on its own, but it adds to a growing pile of scrutiny facing the whole AI infrastructure category, where dozens of well-funded platforms are asking regulated customers to trust them with model weights, prompts, and now, apparently, a directory that lists who those customers are. Due diligence teams evaluating inference vendors should be asking, this week, whether their own build pipelines still expand secrets into RUN commands instead of using BuildKit's --secret mount or a secrets manager fetched at runtime.

Our take

The interesting part of this story isn't that a token leaked. Tokens leak constantly. It's that a single build-time mistake from March 2023 sat untouched for three years and four months inside a company handling inference for enterprise customers, and nobody caught it until an autonomous pentesting agent went looking on its own initiative. That's the actual signal here: the difference between a security program that finds this kind of thing during a routine audit and one that finds out from a researcher's blog post is enormous, and right now most fast-growing infra startups are firmly in the second category. Baseten's response afterward was genuinely good. The three-year gap before that response is the part that should worry anyone reading this while evaluating a similar platform.

Reported by GenZTech from Strix's original disclosure. Source: Strix.