> 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
Good in terms of prompt communication and fix. Absurdly bad in terms of reward.
Earlier in the article, it mentions that Baseten is valued at $13B. They can't dig into their couch cushions to give a few thousand dollars to the researcher privately disclosing a bug that let an attacker escalate to admin in their GitHub org?
This sends the message that honest researchers should not waste their time looking for vulnerabilities in Baseten, but it's a good target for criminals who want to monetize these vulnerabilities.
Yeah companies need to quickly understand that having good actors try and hack you is a good thing - those hacks get reported and another door gets sealed shut for bad actors.
This is more true today than ever before as the bar for a successful attack has never been lower. We’ll see a resurgence of the script-kiddie, or shall I say, vibe-kiddie :-/
It's implied (but sadly not stated) in the post that they asked for baseten's permission before conducting this research.
What's interesting to me as someone who has sold a lot of software to a lot of software companies is that many enterprise vendor agreements explicitly allow companies to pentest their vendors with advance notice and coordination. I don't think any of our clients ever exercised that clause; I expect it's going to be exercised a lot more going forward because it's so easy to do now.
It's not, in most juridictions at least, but it would be insanely stupid for baseten to sue (and the hacker would probably not get much more than a slap on the wrist given that they weren't malicious).
> [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.
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.
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.
The bot snippets talk claudish. I'd say Opus 5. But they must be Cyber Verification Program approved by Anthropic I suppose for the LLM not to block them.
1. A start up is validating a service provider to ensure that they are secure enough so that they can trust them before signing up for their service
2. The service provider is already trusted by so many big name companies who handed over their data, the customers data to them
Should it not be other way around?
On a different note, the finding is not just one off absolute, rather its a symptom which points to certain experience and expertise level for security practices. To be fair its hard to blame the start up folks, they are running against time and cutting corners is somewhat critical for survival for their business
i quite liked using strix. last time i tried it, deepseek was a mess and bloated the context with nonsense. that was ~5 months ago, i wonder how it performs now
Baseten carries the Soc 2 Type II and HIPAA Compliant logos on its front page. They also have logos for customers including: OpenEvidence (medical related, used by almost 2/3 of physicians in the US, claim HIPAA compliance), Harvey (legal related, claim "binding terms on data protection, data access, incident response SLAs, and other controls aligned with SOC2, ISO, GDPR and other standards.")
From TFA:
> 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.
> The image build dated to March 2023, and the token still worked when we found it in July 2026.
Given the build is from 2023 one would expect that at least the token would have been rotated, and I suspect some of these compliance checks do require rotation of tokens/passwords.
That said, the whole compliance industry is a joke.
> 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
Good in terms of prompt communication and fix. Absurdly bad in terms of reward.
Earlier in the article, it mentions that Baseten is valued at $13B. They can't dig into their couch cushions to give a few thousand dollars to the researcher privately disclosing a bug that let an attacker escalate to admin in their GitHub org?
This sends the message that honest researchers should not waste their time looking for vulnerabilities in Baseten, but it's a good target for criminals who want to monetize these vulnerabilities.
[delayed]
Yeah companies need to quickly understand that having good actors try and hack you is a good thing - those hacks get reported and another door gets sealed shut for bad actors.
This is more true today than ever before as the bar for a successful attack has never been lower. We’ll see a resurgence of the script-kiddie, or shall I say, vibe-kiddie :-/
> They also sent us some T-shirts and sweatshirts as a thank-you for finding this critical bug.
Honestly I would have held out for a (hard to get) hardcover copy of Inference Engineering.
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.
It's implied (but sadly not stated) in the post that they asked for baseten's permission before conducting this research.
What's interesting to me as someone who has sold a lot of software to a lot of software companies is that many enterprise vendor agreements explicitly allow companies to pentest their vendors with advance notice and coordination. I don't think any of our clients ever exercised that clause; I expect it's going to be exercised a lot more going forward because it's so easy to do now.
They didn't break in, they found a key that their neighbor dropped and returned it.
It's not, in most juridictions at least, but it would be insanely stupid for baseten to sue (and the hacker would probably not get much more than a slap on the wrist given that they weren't malicious).
> [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.
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.
Let us know if you have any feedback!
If I enter an address to "Start testing", I expect at least a preview of the report rather than being dumped on the signup page.
Yeah understood — we need to make sure you own the domain first though
Just signed up for strix, is it common for these type of products to want access to my Github repo's? Shouldn't the attack surface be outside them?
You can also just do an external pentest -- Github is for continuous CI/CD coverage
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.
Yeah honestly I wasn't too familiar with this beforehand but now have a sense of the best practices going forward
We really are entering the AI economy.
Now if only we knew if the stonks would go up or down (due to global turmoil) before I throw my savings at the SPY
Right now Trump is the wild card you have to take in account. He’s influencing the SPY way more than the AI trade
A Markdown-as-a-Service where the interface is a Docker container.
I get how these choices might be the local optimum for a desired UX, but damn is it depressing to extrapolate where software as a whole is going.
I wonder what model was used for this. Also as far as I know Baseten does not have any abliterated models in their repertoire.
The bot snippets talk claudish. I'd say Opus 5. But they must be Cyber Verification Program approved by Anthropic I suppose for the LLM not to block them.
Either Mythos 5.1 or GPT 5.6 Cyber (aka. GPT Daybreak Red)
Even something like Qwen 3.8 27b could do this.
Lookup certificate transparency and continue from there https://crt.sh/?Identity=baseten.co&exclude=expired&match=IL...
Neither, actually :)
The writing sounds like Claude to me
We were (and still are) considering them as an inference provider and did a quick check first... but kudos to their team for the fast patch
An easily preventable issue with proper engineering culture around defense in depth and principle of least privilege, awful look on Baseten here.
Kudos for Strix to find it, and especially with how it chose to disclose and report it.
This sounds interesting and twisted in some sense
1. A start up is validating a service provider to ensure that they are secure enough so that they can trust them before signing up for their service
2. The service provider is already trusted by so many big name companies who handed over their data, the customers data to them
Should it not be other way around?
On a different note, the finding is not just one off absolute, rather its a symptom which points to certain experience and expertise level for security practices. To be fair its hard to blame the start up folks, they are running against time and cutting corners is somewhat critical for survival for their business
Yeah... interesting paradigm
i quite liked using strix. last time i tried it, deepseek was a mess and bloated the context with nonsense. that was ~5 months ago, i wonder how it performs now
We've made a lot of awesome changes recently, would love any feedback on the latest version :)
Baseten carries the Soc 2 Type II and HIPAA Compliant logos on its front page. They also have logos for customers including: OpenEvidence (medical related, used by almost 2/3 of physicians in the US, claim HIPAA compliance), Harvey (legal related, claim "binding terms on data protection, data access, incident response SLAs, and other controls aligned with SOC2, ISO, GDPR and other standards.")
From TFA:
> 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.
> The image build dated to March 2023, and the token still worked when we found it in July 2026.
What are the legal implications here?
Given the build is from 2023 one would expect that at least the token would have been rotated, and I suspect some of these compliance checks do require rotation of tokens/passwords.
That said, the whole compliance industry is a joke.
Unless github had regulated data, unlikely, the legal implications are few. Document the issue, remediate and no findings on the next audit. Done.
> We build Strix, an autonomous hacking again.
> But... we're a security company.
> So... we pointed Strix at *.baseten.co and let it run without credentials or source code.
lawyers wet dream. and a perfect case. A security company who KNOWS the law unleashed an AI agent to violate the laws