# Baseten's 2023 Container Image Still Had GitHub Admin Access in 2026 **Summary:** Strix found a live token with repository-level admin access in a Baseten image built in 2023. Secret mounts fix the build, but short expiry and narrow permissions contain the forgotten artifact. - Canonical: https://markhuang.ai/news/baseten-2023-build-github-admin-token - Language: en - Author: [Mark Huang](https://markhuang.ai/about) - Published: 2026-09-15 - Section: News - Tags: Baseten, Container Security, GitHub Security, Secrets Management, Supply Chain Security - Source: [Strix](https://www.strix.ai/blog/baseten-harbor-github-pat-takeover) - License: https://creativecommons.org/licenses/by-nc/4.0/ --- ![An old container image layer contains a glowing access key connected to several code and infrastructure vaults](https://cdn.markhuang.ai/news/baseten-2023-build-github-admin-token/hero.webp) *An old image can stop running while the authority buried in its build history stays live.* [Strix reports that its autonomous security agent found](https://www.strix.ai/blog/baseten-harbor-github-pat-takeover) a live GitHub personal access token in a publicly downloadable Baseten container image. The build step was dated March 3, 2023. When Strix tested the token in July 2026, it still had admin and push access to Baseten's main product repository, its Flux configuration repository, and its Homebrew tap. The 25-minute AI hack makes a good headline. I care more about the credential that kept its authority for more than three years. The public registry exposed the artifact, and the Docker build recorded the secret. The token's lifetime and permissions turned two recoverable errors into one critical chain with a route into product code and deployment configuration. If I were reviewing a container pipeline after this disclosure, I would not stop after making the registry private or removing secrets from the current Dockerfile. I would treat every previously published image as a durable record and every build credential as compromised until its scope, expiry, and revocation history proved otherwise. ## The secret was outside the filesystem According to Strix, one Harbor project allowed anonymous pulls, including an image named `baseten/baseten-app`. That behavior matches [Harbor's own project model](https://goharbor.io/docs/main/working-with-projects/create-projects/): any user can pull images from a public project. Public does not automatically mean misconfigured, which is why the consequential finding was inside the image metadata. Strix reports that it pulled the image, scanned its layers, and inspected its config. An AWS credential pair it found was already dead. The GitHub token was not. Its value appeared in `history[].created_by`, where a build command had expanded `GITHUB_TOKEN` into a `RUN` instruction. A read-only `GET /user` request identified the account as `basetenbot`. I would put one detail into every incident checklist: deleting a credential file from a later layer is not enough. Container metadata can preserve the command that created a layer even when the final filesystem looks clean. [Docker explicitly warns](https://docs.docker.com/build/building/secrets/) that build arguments and environment variables are inappropriate for secrets because they can persist in the final image. Docker recommends temporary secret mounts instead. > **Info:** > > My audit boundary would include the image config and complete build history, not only the files in the latest layer. Then I would revoke the exposed credential. Rebuilding the image does not cancel a token already copied elsewhere. ## A dependency fetch did not need admin authority The disclosed build used the token to fetch private GitHub dependencies. Strix says the same credential returned the broad `repo` scope and had admin plus push permission on `basetenlabs/baseten`, `basetenlabs/flux-cd`, and `basetenlabs/homebrew-tap`. It also reported read and write access to other private repositories. Strix says it used read-only requests to establish the permissions, did not clone the customer repository it encountered, and did not push or change configuration. Reading one private dependency calls for access to that dependency. It does not call for standing authority over the product repository, desired cluster state, and a software distribution channel. An attacker holding the token could have had several paths to change what Baseten shipped or deployed. Strix did not report exercising those paths, so I would call them reachable consequences rather than observed compromise. [GitHub's current guidance](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens) recommends fine-grained tokens when possible because they can be limited to one owner, selected repositories, and specific permissions. GitHub also says long-lived organization integrations should use a GitHub App. Fine-grained tokens still have feature gaps, including parts of Packages and Checks, but that is a reason to document an exception. It is not a reason to give a classic token every repository the bot account can reach. I made a similar distinction in [the support-agent refund incident](/news/support-agent-fake-approval-4200-refund): a tool should receive only the authority needed for one bounded action. Here the actor was a build, not a language model, but the containment rule is the same. ## The agent claim is interesting, but secondary Strix says its agent started with a domain, no credentials, and no source code. It found the Harbor registry, proved anonymous image access, rejected a dead credential, located the live token in build history, and checked its reach in about 25 minutes. That sequence is more useful than a scanner that merely reports an exposed registry because it establishes impact without making changes. I would still separate the security finding from the product pitch. Strix sells the autonomous testing system that performed the scan, and the disclosure is its account of the timing and autonomy. I did not find an independent technical postmortem from Baseten. The public article says Baseten reviewed the draft before publication, but that is not the same thing as a separate confirmation of every detail. Whether an agent completed the work in 25 minutes does not change the underlying failure. Harbor documents anonymous pulls for public projects. Docker documents the risk of passing secrets through build arguments. GitHub documents why classic personal access tokens carry a wider blast radius. A human tester with ordinary tools could follow the same path. Automation changes how cheaply and often someone can check forgotten assets. ## Fast response does not erase old exposure Strix reports that it notified Baseten at 11:10 PM on July 13. Baseten made the Harbor project private the next morning, then confirmed at 4:34 PM on July 14 that it had rotated the token and classified the issue as critical. Strix says the remaining findings were closed by July 17. That is a prompt response to a serious report. It still leaves an uncomfortable evidence gap. A token that worked for more than three years requires more than a clean ending. I would want audit logs reviewed for its full practical lifetime, with repository writes, permission changes, package activity, and automation runs tied back to the credential where the records allow it. When [GitHub made fine-grained PATs generally available in 2025](https://github.blog/changelog/2025-03-18-fine-grained-pats-are-now-generally-available/), it also added `token_id` to API audit events so administrators could filter activity by token. That is one more reason to prefer credentials designed for narrower attribution. What I am taking from Baseten's incident is simple: secrets have to expire before artifacts are forgotten. Secret mounts prevent this persistence path, and private registries reduce who can retrieve an image. A short-lived, narrowly scoped credential limits what a missed artifact can unlock. I want those controls together, because a build from 2023 should not still be carrying production-grade authority in 2026.