Baseten GitHub PAT Exposure via Public Harbor Image – How Strix Found Admin Access in 25 Minutes

TL;DR

In July 2026, the autonomous hacking agent Strix uncovered a GitHub personal access token (PAT) embedded in a publicly accessible Docker image from Basename’s Harbor registry. The token, created in March 2023, granted admin and push access to Baseten’s main product repo, GitOps repo, Homebrew tap, and several private customer repositories. The finding was disclosed, the token rotated, and the public registry project privatized within 24 hours.

---

How the vulnerability was discovered

Strix performed black‑box reconnaissance on the *.baseten.co domain, identified a public Harbor registry (gcp-us-east4-zlw.registry.baseten.co), and anonymously pulled the baseten/baseten-app image. After extracting the image manifest and layers, Strix:

1. Ran TruffleHog on the image’s filesystem and config.
2. Detected a GitHub PAT stored in the Docker build history (history[].created_by).
3. Verified the token was still valid by issuing a GET /user request, which returned the account basetenbot.

"The token in the Docker build history, followed by GitHub identifying it as basetenbot. The credential is redacted." – Strix blog post

Scope of the leaked token

GitHub reported the token’s OAuth scope as repo, meaning full repository access. Strix enumerated the repositories reachable by the token and found:

Repository (obfuscated)	Access granted
basetenlabs/b*** (product)	admin: true, push: true
basetenlabs/f*** (GitOps)	admin: true, push: true
basetenlabs/h*** (CLI)	admin: true, push: true
Additional private repos	read/write

These permissions would allow an attacker to:

• Modify the inference platform’s source code.
• Alter GitOps manifests that control production clusters.
• Inject malicious binaries into the CLI distribution channel.
• Access customer‑specific repositories containing potentially sensitive data.

Root cause: leaking build credentials

The token originated from a Docker build step on March 3 2023 that injected a GitHub token via a build argument:

ARG GITHUB_TOKEN
RUN GITHUB_TOKEN=${GITHUB_TOKEN} bash -c '\
  if [[ "${GITHUB_TOKEN}" != "" ]]; then \
    git config --global --add \
      url."https://${GITHUB_TOKEN}@github.com/".insteadOf "git@github.com:"; \
  fi'

Docker records the exact command line in the image’s build history, unintentionally persisting the raw token. The underlying issues were:

• Using a build argument for a secret – Docker stores the value in metadata.
• Persisting the token in Git configuration – Even if the argument were removed later, the credential remained in the image.

Recommended remediation steps

1. Never pass secrets as build arguments. Use Docker BuildKit secret mounts (--secret id=github,src=...) to provide temporary credentials that do not appear in image metadata.
2. Inspect image history with docker history --no-trunc or by downloading the config blob and checking history[].created_by for leaked values.
3. Rotate any exposed tokens immediately and audit all repositories for unauthorized changes.
4. Apply the principle of least privilege: grant build tokens only read access to the specific private dependencies they need, and set short expirations.
5. Privatize container registries that host internal images; avoid exposing them publicly unless deliberately intended.

Disclosure timeline and response

Date & Time	Action
July 13, 2026 11:10 PM	Strix report submitted – live basetenbot token, public Harbor project, repo permissions.
July 14, morning	Baseten made the Harbor project private.
July 14, 4:34 PM	Baseten Security confirmed critical status, rotated the token, requested image deletion.
July 14, 5:05 PM	Reporter confirmed deletion and added two lower‑severity findings.
July 17	Remaining findings closed.
September	Public disclosure prepared and approved.

Baseten’s security team acted quickly, rotating the token and privatizing the registry within hours, and even sent thank‑you swag.

"We thank Strix for their responsible disclosure. We took immediate steps to invalidate the leaked key and remove the public container image. Our logs confirm the vulnerability was never exploited and no customer data was exposed." – Baseten security representative (HN comment)

Community reactions

• Positive feedback – Several commenters praised the rapid remediation and the value of autonomous testing.
• Ethical concerns – Some users questioned whether it was appropriate for a security vendor to run an autonomous agent against a prospective vendor without explicit prior agreement, noting potential legal gray areas.
• Technical observations – Others highlighted that the issue could have been discovered with traditional pen‑testing tools, but emphasized the speed and automation advantage of AI‑driven agents.

Takeaways for operators

• Treat container images as long‑lived attack surfaces – Even old images can contain active secrets.
• Automate secret scanning across both filesystem layers and build metadata.
• Implement short‑lived, scoped tokens for CI/CD pipelines and container builds.
• Run autonomous security agents (like Strix) regularly against your own domains to surface hidden exposures before attackers do.

---

If you rely on GitHub‑based builds or public container registries, audit your existing images today. The cost of a leaked token can be orders of magnitude higher than the effort required to prevent it.