An AI agent found a live admin token for Baseten's GitHub in 25 minutes
We got admin access to Baseten's production GitHub in 25 minutes
Strix, an autonomous hacking agent, scanned Baseten's infrastructure before the company would trust it with data. It found a public Harbor registry, pulled an image, and discovered a GitHub personal access token from a March 2023 build still active in July 2026. The token gave admin and push access to Baseten's main product repo, its GitOps deployment repo, and its Homebrew tap, plus read/write access to private customer repositories. Baseten confirmed the critical issue and rotated the token the next day.
This is an insane amount of access to leave in a publicly downloadable image.
- swyx
> Baseten handled this well. The timeline was:
> July 13, 11:10 PM: I reported the live basetenbot token, the public Harbor project, and the repository permissions.
> July 14, morning: Baseten made the Harbor project private. I flagged that the token itself still worked.
> July 14, 4:34 PM: Anton from Baseten Security confirmed the issue as critical and said they had made the Harbor project private and rotated the token. He also asked us to securely delete the images we'd pulled.
> July 14, 5:05 PM: We confirmed deletion and sent over two lower-severity findings from the same scan.
> July 17: Baseten closed out the remaining findings.
> September: We let Baseten know we planned to disclose the finding publicly and sent them a draft of this post.
They also sent us some T-shirts and sweatshirts as a thank-you for finding this critical bug.
well done all around. i think my only open question is what default security boundaries should all vibecoded internal agents follow as a learning we can take from this
- wxw
> [pen-testing agent] came back with an active GitHub personal access token for basetenbot. That token had admin and push access to Baseten's main product repo, the GitOps repo that drives their clusters, and their Homebrew tap, plus read/write access to other private repositories including specific repos per customers.
And the agent found the token in Docker build history after finding a Baseten image repository.
I wonder how many of these kinds of agent-driven security exploits we're not hearing about these days (i.e. driven by bad actors), worrying.
- aatd86
That is great marketing for strix, pretty bad for baseten.
I don't think someone can have a better story to advertise their own security product.
Did not know about strix but I am going to look it up now.
Might add it to my stack.
- codemog
Is this legal? I know I can’t try and break into my neighbors house even if I have no intent of going inside and stealing once I break the lock.
- nrmitchi
Whether it's valid or not, there is something that rubs me the wrong way about a security tools company using a real customer/vendor as a marketing campaign. This "story" could have been told without naming, bluntly, their "victim".
It would be different if it was some complex, multi-step exploit, but the tone is closer to "look how much Baseten fucked up!".
Strix also crossed the line at this point:
> Strix decided to pull an image and see what was inside.
You're going past the white-hat point here when you start active exfiltrating data and looking at it. Once you start using credentials from the exfiltrated data and start listing and poking around internal systems, you are way past it.
Listen, I get it, their product is "meant for" self-testing, so it assumes it's safe to go digging. After all, it's a self check. That is exactly why it's irresponsible, and borderline illegal, for them to point it at a third party. Even if they had "permission", I dobut that permission extended to "and also search and/or download our repos if you can".
The overall tone is less than professional. Statements like (in bold) "This is an insane amount of access to leave in a publicly downloadable image." Everyone is aware of this, and it's phrase like it was a purposeful decision.
Security tools from teams that actively shit on the people they're designed to "help" feels wrong.
Edit: For clarity on my point about "pulling repos", this post includes descriptions of the purpose and functionality o […]
- grey-area
…by finding an admin token in logs.
- brewmarche
Yeah I have seen this issue a few times. If you use Docker build arguments that way add `--provenance=false` to get rid of all that build metadata. Build secrets are still better since they allow you to scope the secret inside of the Dockerfile. Also, the metadata can be useful to inspect images.
- stopthe
So often recent breaches involve Github in one way or another. How is it still considered a sane choice to host anything proprietary there? If your business is built around open source, ok, put a mirror on Github. But CI/CD, gitops, FDEs' stuff have no place on a public cloud. C-level execs may not know bits from bytes, but by now they should've understood that this is akin to storing ammonium nitrate in the open air.