Old Docker build exposed admin access to Baseten repositories

What this is about

Security company Strix found an active GitHub token inside a publicly downloadable container image while assessing AI inference provider Baseten. According to Strix, the token provided admin and push permissions to internal repositories, including product code, GitOps configuration and a Homebrew repository. Strix reported the finding on July 13, 2026; Baseten restricted the registry project and rotated the token the following day. The technical disclosure was published on September 16, 2026.

The case matters because it required no novel exploit. An old build artifact connected a public registry to a long-lived credential. Teams that build containers or buy AI services therefore need to inspect not only running systems, but also old images and their metadata.

What the token finding actually shows

Strix says it began with an unauthenticated assessment of Baseten domains. Its agent found a Harbor registry containing a public project, downloaded an image and inspected both its layers and build history. An AWS key found first was invalid. But history[].created_by contained a GitHub personal access token that GitHub still associated with the basetenbot account.

The build step was dated March 3, 2023. The token still worked when tested in July 2026 and, according to the redacted responses published by Strix, carried the repo OAuth scope. Strix says it used read-only requests and neither cloned repositories nor pushed changes. Baseten classified the finding as critical, according to the researchers. No separate public technical statement from Baseten was available in the sources reviewed.

Why it matters

Docker explicitly warns that build arguments and environment variables are inappropriate for passing secrets into builds because values can persist in image metadata or history. Even when a file is deleted in a later layer, an earlier layer or configuration record can retain the value. Recommended controls include short-lived, narrowly scoped credentials and BuildKit secret mounts.

Potential misuse would not have been limited to reading source code. Push and admin permissions on product and deployment repositories can affect an entire software supply chain: altered releases, modified infrastructure configuration or compromised update channels would all be plausible outcomes. Strix says its agent found the token in about 25 minutes. That is not an independent benchmark of the product, but it illustrates the low barrier posed by this specific mistake.

In plain language

A container image is like a moving box made from several transparent layers. Removing a key from the top layer does not remove it from a lower one. If the entire box is placed in a public warehouse, someone can inspect every layer and recover the old key.

A practical example

A team builds 20 containers each day and once passes a GitHub token into a build. Three years later, the registry contains 5,000 tags even though only 50 are active. A scanner checks not only files but the complete build history of every reachable image. If it finds a token, the team must revoke it immediately, assess its reach through audit logs, rebuild affected images and remove old artifacts from the registry. Merely changing the current Dockerfile does not end access through a token that has already been copied.

Scope and limits

• The detailed permissions and timeline mainly come from Strix; public evidence is redacted to avoid exposing credentials.
• The reviewed sources contain no evidence that unauthorized parties abused the token before Strix or accessed customer data. Potential access is not a confirmed data breach.
• An automated scanner does not replace permission design or incident response. It can miss findings, create false positives or introduce risk if operated without clear boundaries.

SEO & GEO keywords

Baseten, Strix, GitHub token, Docker build secrets, Harbor registry, container security, software supply chain, BuildKit secret mount, GitOps, repository access