← Back to feed

Security researchers at Strix AI published a post-mortem on September 1 detailing how they obtained admin access to Baseten’s production GitHub in under 25 minutes, with no zero-day exploits required.

The attack vector: a GitHub personal access token belonging to the basetenbot service account was embedded in the layer history of a Docker image (baseten/baseten-app) stored in a publicly accessible Harbor container registry on *.baseten.co. Harbor registries require authentication by default; Baseten’s instance had an unauthenticated public project.

How it unfolded

Strix began with black-box reconnaissance against *.baseten.co subdomains. The team identified a Harbor container registry instance with a publicly accessible project. By pulling the baseten/baseten-app image and inspecting its layer history, they found a GitHub PAT for the basetenbot service account in the created_by field of an image layer.

The token had not been explicitly stored in a configuration file. It was embedded during an image build step and never cleaned out. The standard practice of scrubbing secrets from Docker layers before pushing to any registry had been skipped.

The extracted PAT carried admin-level scope on Baseten’s production GitHub repositories. Total time from starting reconnaissance to confirming access: 25 minutes.

What was at risk

Baseten is a leading AI model deployment platform, valued at $13 billion following a $1.5 billion Series F in June 2026. Production GitHub access at a company of this scale would expose model serving code, API credential stores embedded in code history, deployment pipelines, and internal tooling.

Strix’s agent did not read or exfiltrate any production data beyond confirming the token’s validity and scope.

Responsible disclosure

Strix reported the finding on July 13, 2026. Baseten revoked the GitHub PAT and restricted public access to the Harbor registry the following day. The post-mortem was published on September 1 after the fix was confirmed stable.

Baseten confirmed no customer data was accessed during the research exercise.

The underlying class of vulnerability

Docker layer history is a well-documented credential leak vector. Secrets passed as build arguments or set during image construction steps persist in the layer history unless explicitly cleaned using multi-stage builds, --secret mounts, or post-build squash operations. Images pushed to registries carry that history.

Publicly accessible container registries at major AI infrastructure companies make the exposure surface larger than it appears. The credential is not in code — it is in a compiled artifact — which makes standard secret-scanning tools miss it unless they are configured to scan image layers rather than source files.