Back to archive
Development·Article

Strix says an old Baseten container image exposed a live GitHub admin token

Security company Strix says its autonomous pentesting agent found a live Baseten GitHub personal access token in the build history of a publicly pullable container image. Strix says Baseten treated the issue as critical, made the registry private and rotated the token after disclosure; Baseten has not published an independent incident report.

Published 16 Sept 2026, 08:45

What Strix says it found

Strix says it pointed its autonomous pentesting agent at Baseten’s public internet surface without credentials or source-code access while evaluating the company as a potential inference provider. About 25 minutes later, the agent had found a publicly pullable Harbor image whose Docker build history exposed a working personal access token for a Baseten GitHub account.

According to Strix, the token had admin or push access to Baseten’s main product repository, a GitOps repository used for cluster state and its Homebrew tap, plus read/write access to other private repositories. Strix says the build command that exposed the credential dated from March 2023 and the token still worked when it was found in July 2026.

Why the Docker history mattered

The credential was not simply sitting in the final filesystem of the container. Strix says it was passed during an image build and remained visible in Docker history metadata. Removing a file in a later image layer does not erase earlier build instructions or secrets that were recorded in image history.

The incident is therefore a useful reminder that secret scanning has to cover image layers and build metadata as well as source repositories and the final container filesystem. BuildKit secret mounts and narrowly scoped, expiring credentials reduce the blast radius of this class of mistake.

Disclosure and remediation

Strix says it reported the issue to Baseten on 13 July. Its published timeline says Baseten confirmed the issue as critical, made the relevant Harbor project private and rotated the token by the next afternoon, with remaining findings closed by 17 July.

Strix also says it did not clone customer repositories, push code or modify production configuration. Those statements come from the researcher’s own disclosure, and Baseten has not published a separate incident report that independently reconstructs the exposure.

What the evidence does and does not establish

The primary evidence is a detailed disclosure from the company that found the token, including screenshots and an attack path. That is stronger than a Hacker News headline, but it is still one side of the incident. The claimed permissions and remediation steps therefore remain unverified beyond Strix's disclosure.

The broader lesson is concrete even with that caveat: a long-lived credential embedded in a public container can turn a forgotten build artefact into a software-supply-chain path. Teams that publish images should audit build histories and registry visibility, not only scan current source files.

Source trail

2 sources · 1 primary · 1 discussion