A Strix security disclosure says a publicly readable Baseten container image contained a still-working GitHub personal access token that could reach product and deployment-control repositories. The incident matters to AI infrastructure because a model-serving platform can protect live inference while still exposing its control plane through an ordinary software-supply-chain mistake.
Key facts
- Strix says it anonymously pulled the public
baseten/baseten-appimage and found the token in Docker build history. - The report says the token retained
reposcope and read/write or administrative permissions across several private repositories. - Strix says it reported the finding on July 13; Baseten made the Harbor project private and said it rotated the token on July 14.
- The primary source is Strix’s detailed disclosure.
The technical failure is easy to state and worth dwelling on. Docker image layers preserve build commands. According to Strix, GITHUB_TOKEN was expanded into a RUN command during a March 2023 build. Anyone able to pull the image could inspect that history, recover the value, and make a read-only GitHub request to test it. Strix says that test identified the account as basetenbot. It is the cloud equivalent of writing a master key on a packing slip and then leaving the box on a public loading dock.
The disclosed permissions are what elevate this beyond a stale secret found in unused code. Strix reports access to Baseten’s main product repository, a GitOps repository used to drive clusters, a Homebrew tap, and private repositories, including customer-associated repositories. Its table redacts names, but reports administrative and push privileges on three repositories and private read/write access on four others. A GitOps repository can be particularly consequential because a commit may become a deployment instruction; a package tap can become a distribution path. Those are routes to source and deployment integrity, not proof that either route was used.
The report is explicit about the boundary. Strix says it did not clone customer repositories, push code or modify configuration. It did not report extracting customer prompts, model weights or active deployments, and it did not separately demonstrate that an attacker-controlled commit would execute in continuous integration. That caveat should travel with every retelling. The story is a demonstrated credential and a plausible control-plane path, not evidence of cross-customer data theft.
Baseten’s response is available through the disclosure’s quoted timeline rather than a separate public incident post. Strix says Baseten called the issue critical, secured the registry project, rotated the token and asked the researcher to delete the pulled images. Baseten’s public security practices page describes logical customer separation and namespace isolation; its secure inference documentation describes platform controls. Those materials do not refute the specific supply-chain exposure, nor do they establish any customer impact.
The story is fresh in the September news cycle but not a same-day breach: the disclosure places discovery and remediation in July, followed by public disclosure in September. That chronology is important. It shows responsible reporting and a remediation claim, while leaving the public with no independently auditable account of any historical access logs or impact review.
For AI teams, the operational lesson is broader than Baseten. Container registries are source-distribution systems; build history is part of the attack surface. Secrets must use BuildKit-style secret mounts or equivalent mechanisms that do not persist them in layers, and registries should be private by default with regular anonymous-pull tests. Credentials should be short-lived and scoped so a build token cannot administer deployment infrastructure. Baseten’s reported action—make the project private and rotate the token—addresses immediate exposure; prevention requires controls before a layer is published.
The strongest counterargument is that the claims come from Strix, a security vendor with an interest in showing its research. Here the evidence is nevertheless unusually concrete: a public image, reproducible build-history mechanism, a read-only verification, and a disclosed remediation timeline. The accurate conclusion is not “Baseten was taken over.” It is that a public AI-infrastructure artifact reportedly exposed a production-control credential, a class of failure every model platform should treat as a high-priority supply-chain risk.
Originally published on Ground Truth, where every claim is checked against the primary source.
