Posting this on behalf of our security team. I wanted to confirm that we collaborated with Strix on the remediation of the reported vulnerability. 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.
+1 -- kudos to the Baseten team for their super professional response to all of this, it is clear why they are a generational company (-- Alex from Strix)
> 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.
This is two companies working together. Most of the comments below are assuming this was an independent security researcher doing work on their own time. This was professionals doing work for their companies on both sides.
> 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.
The reason they were looking for bugs was in the context of a B2B relationship, not as a someone independent on their nights and weekends.
If they give them any additional compensation it would probably be in some amount of free or discounted services, which is what they’d want anyway.
Swag packages like these are a token of appreciation not a reward.
The front page post in HN here is worth far more than few thousand dollars , don’t think either organization is operating under purely financial transactional nature .
Most people who find a dropped wallet will return it without evaluating the market value of your compromised identity or the contents of the wallet .
Grateful owners may buy you a beer that doesn’t make them cheap , not everything is evaluated in purely money terms, and that is a good thing ?
> The front page post in HN here is worth far more than few thousand dollars , don’t think either organization is operating under purely financial transactional nature .
not always, especially if its just someone independent. iirc there was a guy here not too long ago who started dropping Windows 0days because Microsoft couldn't be assed to process his bug reports
That actually supports the point that people aren't acting under purely financial motivations. If the guy was purely following financial motivations, surely he would have chosen to sell the vulnerabilities to the shadier side of things. Instead, he dumped them publicly, burning their value while amplifying the "fuck you" factor to Microsoft.
Ignoring reports, or just fixing the vulnerability without acknowledging the work put in by a researcher, is rude and invites rudeness in return.
Microsoft runs a bug bounty program. NightmareEclipse (that’s the researcher’s handle) allegedly participated and Microsoft did not honor their part of the bug bounty program terms.
This is a completely different situation - a company evaluates the security of a prospective vendor prior to entering a business agreement.
> iirc there was a guy here not too long ago who started dropping Windows 0days because Microsoft couldn't be assed to process his bug reports
Did that ever actually happen? I remember him threatening to start dropping 0days and getting a lot of press coverage for it. When I tried to look it up I didn’t find anything at the time.
“Nightmare Eclipse released these zero-day exploits as part of an ongoing dispute with Microsoft over the company's bug bounty and vulnerability disclosure practices. […] Since April, the anonymous security researcher has disclosed a long list of zero-day flaws, including ShieldBreak, LegacyHive, RoguePlanet, BlueHammer, RedSun, YellowKey, GreenPlasma, MiniPlasma, and UnDefend, targeting Microsoft Defender, BitLocker, and other Windows components.”
Wallets usually belong to real people with lives. We can empathize with them. Companies are not people. And they also don't and can't empathize with you.
>Wallets usually belong to real people with lives.
So does data ? it belongs to real people.
I would imagine baseten's customers and eventually their end-users[1] were also grateful that their data was not compromised here and the disclosure was responsible.
[1] There is a pretty good chance you and I could be using services who are using baseten
"and can't empathize with you" - I don't really understand why such a perception of companies has been regurgitated and reinforced so much in US public, to the point where it's a blank excuse from ever expecting such a thing from a company. It's not true that it can't. The only reason to keep repeating that kind of worldview is to absolve companies behaving in shitty, toxic or downright evil ways.
The law doesn't say companies MUST choose the most profitable choice at every turn, and even explicitly allows for good treatment of customers, community, employees etc as a viable business strategy (even if it's sad that it must be justified in that way).
I think the only misleading part of this situation is your naive and self-centered definition of "trust", and the assumption that so many others think similarly enough that they need to be warned.
I trust a business to fulfill their obligations as stated in writing for the money paid. I do not trust them in any other way. Nobody should "trust" or depend on undefined behavior. Common sense can only ever be as common as you expect.
I agree that this notion that companies make these decisions is bad, bad on the grounds that it's people working for those companies that make the decisions, they hide themselves away, but the company itself isn't doing anything - is always a human making the decision
I think the point is that companies are purely legal entities, and as such, cannot feel, much less empathize, simply by virtue of them not being living things
That's nonsense. "Companies" are not something non-human, they are run by humans, who do feel, empathize, and are living beings. Without these living-being humans, there would simply be no "company".
Now how those humans that run the company behave is another thing - they are free to be greedy assholes, and a lot of them are, and some of them aren't - but that's still a human thing.
Companies are 100% people. The fact that companies, their CEOs, and employees are not treated like people is exactly reason why humanity is in the shitshow show it is right now.
This was a potential customer reporting a result of an audit of a tool they are evaluating. This is frequent and normal activity in enterprise deals. Most of the time such reports are not critical vulnerabilities it would things like tenant configuration -what business would like versus what CISO will accept or risk acceptance of the product they are buying with monitoring or other prescription on access restrictions or a DPA and so on.
It would be novel business model to spend ton of money in getting a prospect to late-deal stage where they are ready to do a security audio for you just so that part is "free" .
Most companies wouldn't disclose(to the public) even if it was serious , that is not their job, they will report to internal teams and re-review on fix. Strix.ai has a benefit in doing so as they sell a scanning tool for this purpose so we get to hear of this.
First, you're being petty and just fighting fire with fire. Second, most of this research is fairly trivial.
What you're instead encouraging is a race to the bottom. You're not going to kill off the companies you hate by withholding information. You don't even have that power anyway because by its very nature, security research is not secret. You're really just encouraging pessimistic groupthink and bad faith. This is why businesses can't be more open about their flaws. It's not that they're stupid and incompetent, but that the pitchforks come out. These are the seeds of dystopia.
They would have eventually figured it out, but as an unfortunate incident with an outsized effect. As much as you wish it to be true, even the worst of these incidents will not kill their business. As much as you hate these businesses, their financial momentum will eventually cause the public to depend on them more. There's more at stake here than anyone's personal gain. It's naive to think otherwise.
You're just manifesting broken windows and ignoring litter thinking you're fighting the man. This is straight up ghetto punk ass behavior wearing a white collar.
> You're just manifesting broken windows and ignoring litter thinking you're fighting the man. This is straight up ghetto punk ass behavior wearing a white collar.
are you replying to the right person?
I'm not hating on any business or trying to "kill" any business.
I'm saying serve yourself, not them. if you have say, a 0 day on your hands, do what serves you best.
> I'm saying serve yourself, not them. if you have say, a 0 day on your hands, do what serves you best. is that "ghetto punk ass behavior"?
Yes.
If you have say, managed to find an overlooked passage into an ostensibly high security building, "doing what serves you best" such as selling the information to some thugs, is in fact that kind of behavior.
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 :-/
The researcher in this case was doing a security review for their company who was a potential customer. Sending potential customers more than a token amount of cash is usually prohibited by corporate ethics rules for obvious reasons.
That's incorrect. It's not only perfectly acceptable, but absolutely vital, to pay someone for their services (incl a customer) for assisting with an existential threat against the corporation.
Any counsel or HR who would draft a corporate ethics rule that wouldn't allow for a bug bounty to be paid out on a massive vulnerability, merely because the person was "a potential customer", should be immediately replaced.
> 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.
of course, these companies want you to sell vulns to brokers and other orgs. they don't care about bug reports.
This is probably still considered standard response timeline, not a rapid one.
The time window allowing for CVEs + Vulnerabilities remediation has been collapsing to days and hours perhaps even minutes[1]. Anyone who has an OpenRouter account can start using Strix + GLM 5.3 Flash to do damages at frontier Mytho 5 level cyber capabilities. [2]
This cyber patching race is on, won't stop until all the software created for the past 70 years still in active use needs to be patched up. This is happening at EVERY SINGLE software company.
Meanwhile I have customers running legacy web apps last compiled over five years ago on end-of-life operating systems… and it’s crickets chirping. Dead quiet, not even a hint of an attack, let alone a breach.
I expected them to have been hacked to pieces by now, but even “maximally vulnerable” internet-facing apps seem to be relatively unmolested so far.
Maybe it’s still too expensive to go after “boring” enterprise targets? Maybe the bad actors targeted crypto systems first for the immense payoffs, if successful?
It's a risk-reward ratio, same as anything else, whether legal or illegal.
You wouldn't organise the equivalent of an elaborate bank heist to break into a child's piggy bank, it's just not worth it.
I have heard of a few high profile crypto heists that appear to be AI-assisted, some as far back as the GPT 3.5 era. There was an article I can't find any more about someone accidentally pushing a security fix to a public repo and getting their wallets drained via that specific mechanism within something like an hour.
Malicious actors are watching crypto like a cat in front of a mouse hole, because a "success" can net them the equivalent of hundreds of millions of USD that they can instantly transfer, launder, and spend.
For comparison, what would they achieve by hacking the web site of a local council or public library? Cause some embarrassment? Attempt to crypto-locker them? What are the chances of a payout? Certainly not a 100%, and you're also certain to get the attention of the local equivalent of the FBI or Homeland Security.
I’d treat a vibecoded agent like an untrusted CI job, not like a junior employee: repo-scoped identity, read-only by default, no inherited Actions token or production secrets. Any operation that turns a read into a write should require approval outside the agent’s control and produce an auditable diff. Network egress belongs in the boundary too. Read-only access is not much protection if the agent can send everything it reads to an arbitrary endpoint.
Of course, it's impossible to know for sure what was LLM processed or not, but some of your posts (like this one) have been getting classified that way.
This fits neatly into the category of "not something an unmotivated huamn would bother to look for, but absolutely something a human could find if they were interested."
It increasingly feels like the power of these agents is less that they find things humans COULDN'T find, and more that they find many things much more quickly than humans would bother to do.
I don't know if this is a great advert for Strix over other agents - what did their agent do that Claude or Codex couldn't? It didn't do anything that I couldn't do, if I wanted to.
As a security software engineer I value and have a lot of experience with disclosures like this. At the last two B2Bs I worked at, I would also work personally with prospect security teams that wanted to run their red team at us (with approval and rules of engagement)
This is a valuable disclosure but I wonder about two things:
a) was the decision to run Strix against a prospective vendor domain negotiated in advance?
b) if the answer to a) is “no” then it is apparent that while Strix want to ensure their customers only run it against domains they own (totally fair) they have a double standard for their own use.
I don’t know, I’m accustomed to getting disclosures from any Jane or Joe via bug bounties etc., but it feels like a courtesy notice would be nice before a prospective customer lets their agentic hacker off the leash.
> [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.
This is impressive and something a human will never bother to find. But please stop saying Strix then did, Strix then went, Srix then this, then that. My monkey brain just can’t accept an LLM being referred to as if it is a living being with autonomy. It’s not.
I’ll accept when we actually see AI models.
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.
> 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.
They didn't break in. They found a key that their neighbor dropped and returned it.
> Is this legal?
Generally, yes (though ask a lawyer if you're going to do security work). Security researchers do occasionally get legal flak though, depending on which idiot they annoy by pointing out issues.
IAAL (not legal advice, consult a lawyer in your jurisdiction). You really do not want to pen-test a target without their permission. If you're identified as a culprit, the Feds will shove the CFAA so far up your ass you'll need a proctologist.
as a lawyer, can you speculate as to why anthropic/openai aren't facing many or any consequences for their agents? I'm not asking in a "grab the pitchforks" way. more out of genuine curiosity as my uninformed recollection of the CFAA is as you describe it.
In Perplexity's case everything is getting routed through the user's browser, so there is no server to server communication between Perplexity and Amazon, thus no CFAA unauthorized access was established. However, Anthropic and OpenAI did not use the pattern of routing through authorized parties, so I don't think this opinion gives them any cover.
The important bit to me is that they consider the agent running as an extension of the user. So the user is visiting Amazon, not Perplexity.
From that lens, that feels like users could be held liable for what these hacking agents are doing. Which in some cases probably makes sense, but certainly not all.
In cases where the user is not asking the agent to hack anything specifically, but a poor or ambiguous query sets the agent off.
I've seen plenty of cases of Claude having an action blocked so trying tons of workarounds to accomplish its goal, I could easily see it doing this on something more broad.
Depending on the circumstances, failure to control your agent could be considered gross negligence and put you at risk of criminal or civil liability. Be mindful!
There is also the big difference here between anthropic/openai maybe being negligent, but did not purposely instruct agents to go commit crimes.
The service that this whole thread is about is explicitly a "hacking agent", designed explicitly to try to hack things, and was then pointed at a third-party (seemingly without their permission).
Anthropic/OpenAI can reasonably claim that they had no intent and are trying to stop it. OP here did this explicitly and purposely.
I never thought I'd be on the side of advocating for a strengthened CFAA, but the mens rea requirement here seems really problematic in the age of agents.
In terms of negligence use (openai, anthropic), ya, I agree, and we really need some consideration of "reasonable expectation" of the outcome.
In terms of "We wrote a hacking agent designed only for hacking and sell it as a self-hacking service and then pointing it at someone else and omg can you believe what it did we had no intention of hacking" sense, I don't think that's really applicable.
The mens rea is explicitly there and it's not valid for them to try to hide behind an "agent".
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 is no wonder that there is an anarchist counterculture there. I find anarchism to be really disturbing in general, but in the context of Germany, it might make a lot more sense.
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).
What did I miss they did that's illegal? It looked like it downloaded a public docker image, searched around inside, and verified that the key it found was still valid (without making any changes), and then immediately notified them about the issue.
If there is anything that was a crime (and it totally depends on jurisdiction), it was verifying the key. They used it to see what it could access, and by using it they had unauthorised access to a system
They "validated that the key was valid" by iterating internal repositories and listing the contents of said repos and poking around at what they do/are-for, including, apparently, iterating through customer lists/information.
The white-hat line stops at "validated the key was valid". It does not extend to "poking around inside to extract business-confidential customer information".
The fact that they don’t seem to explicitly state this fact but do go to lengths to explain how the agent didn’t do anything malicious while confirming how alive the token was makes me doubt they asked for permission to run the agent in the first place.
That's highly unlikely since it's standard practice in the industry, thus it's unnecessary to state it. Also, they didn't hack a hobby developer's website, but a prospective business partner who has enough money to sue them into oblivion. No way this wasn't announced.
Announcing that their agent restrained itself even though it got hold of a live token is necessary to convince prospective clients. You don't want a pentester that doesn't show this kind of reserve!
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 of multiple repos (which is past what a name gives them), and they explicitly state: "A listing of that private repo showed a top-level customers/ directory, with subdirectory after subdirectory named after Baseten customers". Strix explicitly took action that they knew they were not permitted, and extracted confidential customer information. Claiming "We didn't clone the customer repo" when you, instead, just listed the contents of the repo, is not a valid defense.
Agreed. I suppose they'd have slightly less credibility by saying "we hacked <unnamed company>" but it strikes me as far classier than naming & shaming.
I'm not sure this is "naming and shaming" because I don't seen an intent to shame. They disclosed the vulnerability privately, waited months for patches, and were commended by the organization with the vulnerabilities.
There's no shame here, this was a mistake, probably made by a human, and ultimately corrected. Nobody seems upset by the outcome!
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.
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.
Github personal access tokens are security footguns. This is an apparently old and forgotten image containing a token from 2023 and it the token gets you admin acces to their repos.
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
It may make sense to change security practices so nothing has long term access. Everything should be rotated monthly, and maybe within a few years, hourly.
Running a one-person SaaS, the honest failure mode isn't "we decided not to rotate", it's "rotation isn't automated so it just never happens". A stale token from 2023 still being alive in 2026 says less about policy and more about nobody having a reason to touch that code path in three years.
For a small team the fix that actually sticks is having the platform expire things by default (short-lived tokens, forced re-issue) rather than relying on a human remembering to rotate on a calendar. That calendar reminder is competing with every other thing on a solo dev's plate, and it reliably loses.
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
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.
> So Strix enumerated hosts, looked through certificate logs, mapped the full surface.
If there is anything that you should do while setting up infrastructure... it is getting rid of single-host SSL certificates. If you're on Amazon... just let it issue wildcard certificates and place an ALB in front of hosts that terminates the SSL connection. The very second a subdomain appears in any of the CT logs directly, you've lost, it will get hammered.
And keep your public and private Git, Docker, npm and whatnot registries separate infrastructure, with the private stuff only reachable from within the corporate network, preferably just servers. Too many a company got hacked and lost significant data because of someone exploiting a GitLab RCE on an instance that hosted both private and intentionally-public repositories. (Yes, I have been there.)
> It is their GitOps: the repository contains the desired state of the clusters, and it applies that state to the infrastructure.
That's another thing I frankly do not get why people are still doing it.
It's fine to have a Git pipeline do a lint, even a terraform plan using a read-only token (although that token needs access to the statefile aka s3 bucket... and there will be relevant secrets there). But, IMHO, a terraform apply should always, always be run on a machine of a sysadmin manually doing the apply. A human, you can hold accountable, and you can keep them at a good security posture with short-lived session tokens. But a Git pipeline where there is a cloud provider token with full admin permissions? That is one Gitlab RCE patch or Github issue away from being compromised.
Besides, one repository holding all the IaC stuff? That just sounds like hour long `terraform refresh` sessions.
> A human, you can hold accountable, and you can keep them at a good security posture with short-lived session tokens.
You can do this too (and better) with a repo: OIDC/Workload identity trust relationship between github and aws for short lived tokens + a github environment setup that requires manual approval.
Bonus: It also gives you an audit trail with a github action log as opposed to a sysadmin running something on a laptop.
The problem here was mostly that they (for some reason) happened to use (and leak) a PAT.
> Besides, one repository holding all the IaC stuff? That just sounds like hour long `terraform refresh` sessions.
If it is terraform, then typically it's split up into multiple "root modules" which get planned and applied separately, even though it's all in one repo.
if i find someones key on the ground and take the key and walk into their house and poke around, and make sure to leave a letter, this is a good thing?
The part that matters more than the public Harbor project: the image was built in March 2023 and the token still worked when they found it in July 2026. Over three years. That is a classic PAT with no expiry, which GitHub still lets you create and which is still the easiest thing to reach for when you are wiring up a bot account.
Secret scanning would not have caught it either. It reads repositories, not image layers sitting in a registry on your own subdomain, so the coverage stopped exactly where the leak was.
Anton here from the baseten security team. I wanted to confirm that we collaborated with Strix on the remediation of the reported vulnerability. 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 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.
Hey all Philip from Baseten here.
Posting this on behalf of our security team. I wanted to confirm that we collaborated with Strix on the remediation of the reported vulnerability. 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.
> Our logs confirm
You retain all logs back through to (at least) March 2023?
You don't?
For some stuff, I've got logs going back to 1993...
+1 -- kudos to the Baseten team for their super professional response to all of this, it is clear why they are a generational company (-- Alex from Strix)
What distinguishes their response from non-generational companies? Do others fail to rotate their exposed github secrets that have admin access?
see, non-generational companies often miss the chance to turn penetration testing into a marketing opportunity
> 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.
> Absurdly bad in terms of reward
This is two companies working together. Most of the comments below are assuming this was an independent security researcher doing work on their own time. This was professionals doing work for their companies on both sides.
> 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.
The reason they were looking for bugs was in the context of a B2B relationship, not as a someone independent on their nights and weekends.
If they give them any additional compensation it would probably be in some amount of free or discounted services, which is what they’d want anyway.
The main payment is all the viral advertising that this AI hacking tool is getting right now. Hard to put a price on that.
Literally paid in exposure.
Swag packages like these are a token of appreciation not a reward.
The front page post in HN here is worth far more than few thousand dollars , don’t think either organization is operating under purely financial transactional nature .
Most people who find a dropped wallet will return it without evaluating the market value of your compromised identity or the contents of the wallet .
Grateful owners may buy you a beer that doesn’t make them cheap , not everything is evaluated in purely money terms, and that is a good thing ?
> The front page post in HN here is worth far more than few thousand dollars , don’t think either organization is operating under purely financial transactional nature .
not always, especially if its just someone independent. iirc there was a guy here not too long ago who started dropping Windows 0days because Microsoft couldn't be assed to process his bug reports
That actually supports the point that people aren't acting under purely financial motivations. If the guy was purely following financial motivations, surely he would have chosen to sell the vulnerabilities to the shadier side of things. Instead, he dumped them publicly, burning their value while amplifying the "fuck you" factor to Microsoft.
Ignoring reports, or just fixing the vulnerability without acknowledging the work put in by a researcher, is rude and invites rudeness in return.
Microsoft runs a bug bounty program. NightmareEclipse (that’s the researcher’s handle) allegedly participated and Microsoft did not honor their part of the bug bounty program terms.
This is a completely different situation - a company evaluates the security of a prospective vendor prior to entering a business agreement.
> iirc there was a guy here not too long ago who started dropping Windows 0days because Microsoft couldn't be assed to process his bug reports
Did that ever actually happen? I remember him threatening to start dropping 0days and getting a lot of press coverage for it. When I tried to look it up I didn’t find anything at the time.
> New Microsoft Defender 'ShieldCrash' zero-day grants SYSTEM access
https://bleepingcomputer.com/news/security/new-microsoft-def...
“Nightmare Eclipse released these zero-day exploits as part of an ongoing dispute with Microsoft over the company's bug bounty and vulnerability disclosure practices. […] Since April, the anonymous security researcher has disclosed a long list of zero-day flaws, including ShieldBreak, LegacyHive, RoguePlanet, BlueHammer, RedSun, YellowKey, GreenPlasma, MiniPlasma, and UnDefend, targeting Microsoft Defender, BitLocker, and other Windows components.”
Wallets usually belong to real people with lives. We can empathize with them. Companies are not people. And they also don't and can't empathize with you.
>Wallets usually belong to real people with lives.
So does data ? it belongs to real people.
I would imagine baseten's customers and eventually their end-users[1] were also grateful that their data was not compromised here and the disclosure was responsible.
[1] There is a pretty good chance you and I could be using services who are using baseten
"and can't empathize with you" - I don't really understand why such a perception of companies has been regurgitated and reinforced so much in US public, to the point where it's a blank excuse from ever expecting such a thing from a company. It's not true that it can't. The only reason to keep repeating that kind of worldview is to absolve companies behaving in shitty, toxic or downright evil ways.
The law doesn't say companies MUST choose the most profitable choice at every turn, and even explicitly allows for good treatment of customers, community, employees etc as a viable business strategy (even if it's sad that it must be justified in that way).
> The only reason to keep repeating that kind of worldview is to absolve companies behaving in shitty, toxic or downright evil ways.
Or...to warn people away from ever expecting compassionate or empathetic behaviour from companies, and remind people not to trust them?
I think the only misleading part of this situation is your naive and self-centered definition of "trust", and the assumption that so many others think similarly enough that they need to be warned.
I trust a business to fulfill their obligations as stated in writing for the money paid. I do not trust them in any other way. Nobody should "trust" or depend on undefined behavior. Common sense can only ever be as common as you expect.
> your naive and self-centered definition of "trust"
I never gave one? For what it's worth, I agree with your second paragraph, despite your first being needlessly aggressive.
I agree that this notion that companies make these decisions is bad, bad on the grounds that it's people working for those companies that make the decisions, they hide themselves away, but the company itself isn't doing anything - is always a human making the decision
I think the point is that companies are purely legal entities, and as such, cannot feel, much less empathize, simply by virtue of them not being living things
That's nonsense. "Companies" are not something non-human, they are run by humans, who do feel, empathize, and are living beings. Without these living-being humans, there would simply be no "company".
Now how those humans that run the company behave is another thing - they are free to be greedy assholes, and a lot of them are, and some of them aren't - but that's still a human thing.
Companies are 100% people. The fact that companies, their CEOs, and employees are not treated like people is exactly reason why humanity is in the shitshow show it is right now.
Thank you for pushing back on one of the top disruptive bad-faith comments we see on HN.
The follow up arguments will be that since billion dollar companies ultimately only care about their bottom line, so should we.
I'm certain most of these comments mean well (to "open eyes" or whatever), but some of them really are on principle and blatant astroturfing.
> The follow up arguments will be that since billion dollar companies ultimately only care about their bottom line, so should we.
so it should be fought by giving them free work in the hopes that they'll finally feel guilty and then start paying proper bounties?
like to me that just seems funny, as if they'd change anything if we'd keep rewarding them for not doing the right thing
like, there's a reason regulation exists for all kinds of shit because otherwise companies would do all kinds of atrocities in hopes of cutting costs
> free work
Don't know if I would call it that ?
This was a potential customer reporting a result of an audit of a tool they are evaluating. This is frequent and normal activity in enterprise deals. Most of the time such reports are not critical vulnerabilities it would things like tenant configuration -what business would like versus what CISO will accept or risk acceptance of the product they are buying with monitoring or other prescription on access restrictions or a DPA and so on.
It would be novel business model to spend ton of money in getting a prospect to late-deal stage where they are ready to do a security audio for you just so that part is "free" .
Most companies wouldn't disclose(to the public) even if it was serious , that is not their job, they will report to internal teams and re-review on fix. Strix.ai has a benefit in doing so as they sell a scanning tool for this purpose so we get to hear of this.
At some point, you will realize two things.
First, you're being petty and just fighting fire with fire. Second, most of this research is fairly trivial.
What you're instead encouraging is a race to the bottom. You're not going to kill off the companies you hate by withholding information. You don't even have that power anyway because by its very nature, security research is not secret. You're really just encouraging pessimistic groupthink and bad faith. This is why businesses can't be more open about their flaws. It's not that they're stupid and incompetent, but that the pitchforks come out. These are the seeds of dystopia.
They would have eventually figured it out, but as an unfortunate incident with an outsized effect. As much as you wish it to be true, even the worst of these incidents will not kill their business. As much as you hate these businesses, their financial momentum will eventually cause the public to depend on them more. There's more at stake here than anyone's personal gain. It's naive to think otherwise.
You're just manifesting broken windows and ignoring litter thinking you're fighting the man. This is straight up ghetto punk ass behavior wearing a white collar.
> You're just manifesting broken windows and ignoring litter thinking you're fighting the man. This is straight up ghetto punk ass behavior wearing a white collar.
are you replying to the right person?
I'm not hating on any business or trying to "kill" any business.
I'm saying serve yourself, not them. if you have say, a 0 day on your hands, do what serves you best.
is that "ghetto punk ass behavior"?
what are you on about?
> I'm saying serve yourself, not them. if you have say, a 0 day on your hands, do what serves you best. is that "ghetto punk ass behavior"?
Yes.
If you have say, managed to find an overlooked passage into an ostensibly high security building, "doing what serves you best" such as selling the information to some thugs, is in fact that kind of behavior.
It's nice to wax poetic, but they should absolutely pay the researchers here.
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 :-/
The researcher in this case was doing a security review for their company who was a potential customer. Sending potential customers more than a token amount of cash is usually prohibited by corporate ethics rules for obvious reasons.
That's incorrect. It's not only perfectly acceptable, but absolutely vital, to pay someone for their services (incl a customer) for assisting with an existential threat against the corporation.
Any counsel or HR who would draft a corporate ethics rule that wouldn't allow for a bug bounty to be paid out on a massive vulnerability, merely because the person was "a potential customer", should be immediately replaced.
of course not, all they can do is a lil "thx"
> 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.
of course, these companies want you to sell vulns to brokers and other orgs. they don't care about bug reports.
otherwise they'd pay as much or even more, right?
This is probably still considered standard response timeline, not a rapid one.
The time window allowing for CVEs + Vulnerabilities remediation has been collapsing to days and hours perhaps even minutes[1]. Anyone who has an OpenRouter account can start using Strix + GLM 5.3 Flash to do damages at frontier Mytho 5 level cyber capabilities. [2]
This cyber patching race is on, won't stop until all the software created for the past 70 years still in active use needs to be patched up. This is happening at EVERY SINGLE software company.
The cost of not doing it? Game over.
[1]: https://news.ycombinator.com/item?id=49699402
[2]: https://news.ycombinator.com/item?id=49705036
Meanwhile I have customers running legacy web apps last compiled over five years ago on end-of-life operating systems… and it’s crickets chirping. Dead quiet, not even a hint of an attack, let alone a breach.
I expected them to have been hacked to pieces by now, but even “maximally vulnerable” internet-facing apps seem to be relatively unmolested so far.
Maybe it’s still too expensive to go after “boring” enterprise targets? Maybe the bad actors targeted crypto systems first for the immense payoffs, if successful?
> it’s still too expensive to go after “boring” enterprise targets?
The economic argument seems convincing to me. I can’t tell what your stance on it is.
You’re the only one that knows the value of these targets, but “not worth it” seems likely to me.
It's a risk-reward ratio, same as anything else, whether legal or illegal.
You wouldn't organise the equivalent of an elaborate bank heist to break into a child's piggy bank, it's just not worth it.
I have heard of a few high profile crypto heists that appear to be AI-assisted, some as far back as the GPT 3.5 era. There was an article I can't find any more about someone accidentally pushing a security fix to a public repo and getting their wallets drained via that specific mechanism within something like an hour.
Malicious actors are watching crypto like a cat in front of a mouse hole, because a "success" can net them the equivalent of hundreds of millions of USD that they can instantly transfer, launder, and spend.
For comparison, what would they achieve by hacking the web site of a local council or public library? Cause some embarrassment? Attempt to crypto-locker them? What are the chances of a payout? Certainly not a 100%, and you're also certain to get the attention of the local equivalent of the FBI or Homeland Security.
Anyone can push people onto the railway tracks at a metro station but they don't. Being able to cause damage doesn't mean people will.
I’d treat a vibecoded agent like an untrusted CI job, not like a junior employee: repo-scoped identity, read-only by default, no inherited Actions token or production secrets. Any operation that turns a read into a write should require approval outside the agent’s control and produce an auditable diff. Network egress belongs in the boundary too. Read-only access is not much protection if the agent can send everything it reads to an arbitrary endpoint.
Can you please not post AI-generated or AI-edited comments to HN? It's not allowed here - see https://news.ycombinator.com/newsguidelines.html#generated and https://news.ycombinator.com/item?id=47340079.
Of course, it's impossible to know for sure what was LLM processed or not, but some of your posts (like this one) have been getting classified that way.
> 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.
signed too!
This fits neatly into the category of "not something an unmotivated huamn would bother to look for, but absolutely something a human could find if they were interested."
It increasingly feels like the power of these agents is less that they find things humans COULDN'T find, and more that they find many things much more quickly than humans would bother to do.
I don't know if this is a great advert for Strix over other agents - what did their agent do that Claude or Codex couldn't? It didn't do anything that I couldn't do, if I wanted to.
As a security software engineer I value and have a lot of experience with disclosures like this. At the last two B2Bs I worked at, I would also work personally with prospect security teams that wanted to run their red team at us (with approval and rules of engagement)
This is a valuable disclosure but I wonder about two things:
a) was the decision to run Strix against a prospective vendor domain negotiated in advance?
b) if the answer to a) is “no” then it is apparent that while Strix want to ensure their customers only run it against domains they own (totally fair) they have a double standard for their own use.
I don’t know, I’m accustomed to getting disclosures from any Jane or Joe via bug bounties etc., but it feels like a courtesy notice would be nice before a prospective customer lets their agentic hacker off the leash.
EDIT: for typos.
> [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.
This is impressive and something a human will never bother to find. But please stop saying Strix then did, Strix then went, Srix then this, then that. My monkey brain just can’t accept an LLM being referred to as if it is a living being with autonomy. It’s not. I’ll accept when we actually see AI models.
>something a human will never find
Eh, yes it is. And something that humans find all the time.
They even call out a non-AI tool that helped.
Corrected
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.
I'd never heard of baseten before; now I know who they are. "There is no such thing as bad publicity".
They are a great team! You will defacto also use Caido if you add it to your 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
Might be too nerdy for some, but a TXT DNS rule could work. That or a sample report. It looks like a cool product though, thanks for sharing.
Is there a sample report somewhere to get a feel for the output?
yes! app.strix.ai/demo
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.
> 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.
They didn't break in. They found a key that their neighbor dropped and returned it.
> Is this legal?
Generally, yes (though ask a lawyer if you're going to do security work). Security researchers do occasionally get legal flak though, depending on which idiot they annoy by pointing out issues.
IAAL (not legal advice, consult a lawyer in your jurisdiction). You really do not want to pen-test a target without their permission. If you're identified as a culprit, the Feds will shove the CFAA so far up your ass you'll need a proctologist.
as a lawyer, can you speculate as to why anthropic/openai aren't facing many or any consequences for their agents? I'm not asking in a "grab the pitchforks" way. more out of genuine curiosity as my uninformed recollection of the CFAA is as you describe it.
The 9th Circuit Court of appeals recently published this that is somewhat related (Amazon v. Perplexity): https://cases.justia.com/federal/appellate-courts/ca9/26-144...
Look at pages 10-17 to see how the law is evolving here.
In Perplexity's case everything is getting routed through the user's browser, so there is no server to server communication between Perplexity and Amazon, thus no CFAA unauthorized access was established. However, Anthropic and OpenAI did not use the pattern of routing through authorized parties, so I don't think this opinion gives them any cover.
The important bit to me is that they consider the agent running as an extension of the user. So the user is visiting Amazon, not Perplexity.
From that lens, that feels like users could be held liable for what these hacking agents are doing. Which in some cases probably makes sense, but certainly not all.
In which cases wouldn’t it make sense?
In cases where the user is not asking the agent to hack anything specifically, but a poor or ambiguous query sets the agent off.
I've seen plenty of cases of Claude having an action blocked so trying tons of workarounds to accomplish its goal, I could easily see it doing this on something more broad.
Depending on the circumstances, failure to control your agent could be considered gross negligence and put you at risk of criminal or civil liability. Be mindful!
There is also the big difference here between anthropic/openai maybe being negligent, but did not purposely instruct agents to go commit crimes.
The service that this whole thread is about is explicitly a "hacking agent", designed explicitly to try to hack things, and was then pointed at a third-party (seemingly without their permission).
Anthropic/OpenAI can reasonably claim that they had no intent and are trying to stop it. OP here did this explicitly and purposely.
I never thought I'd be on the side of advocating for a strengthened CFAA, but the mens rea requirement here seems really problematic in the age of agents.
In terms of negligence use (openai, anthropic), ya, I agree, and we really need some consideration of "reasonable expectation" of the outcome.
In terms of "We wrote a hacking agent designed only for hacking and sell it as a self-hacking service and then pointing it at someone else and omg can you believe what it did we had no intention of hacking" sense, I don't think that's really applicable.
The mens rea is explicitly there and it's not valid for them to try to hide behind an "agent".
> They didn't break in. They found a key that their neighbor dropped and returned it.
Ya, returned it after poking through all of the drawers and iterating through business information that they found.
There is a white-hat line that OP very clearly crossed here.
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.
Your intuitution is right. At least in Germany it is not legal if not asked for permission first.
https://www.nilsbecker.de/rechtliche-grauzonen-fuer-ethische...
See also the German Criminal Code, starting with §202a "Data espionage":
https://www.gesetze-im-internet.de/englisch_stgb/englisch_st...
Germany isnt a serious country though Decompilng code is illegal there
It is no wonder that there is an anarchist counterculture there. I find anarchism to be really disturbing in general, but in the context of Germany, it might make a lot more sense.
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).
Suing is not what you do when someone commits a crime against you. You're confusing civil law and criminal law.
Yes, or more precisely I don't confuse the concepts but the terminology since English isn't my first language.
> It's not, in most juridictions at least
What did I miss they did that's illegal? It looked like it downloaded a public docker image, searched around inside, and verified that the key it found was still valid (without making any changes), and then immediately notified them about the issue.
If there is anything that was a crime (and it totally depends on jurisdiction), it was verifying the key. They used it to see what it could access, and by using it they had unauthorised access to a system
The CFAA is broad enough to make that a crime.
They "validated that the key was valid" by iterating internal repositories and listing the contents of said repos and poking around at what they do/are-for, including, apparently, iterating through customer lists/information.
The white-hat line stops at "validated the key was valid". It does not extend to "poking around inside to extract business-confidential customer information".
People have been arrested for far less. I dunno what the least offensive conviction has been though tbf. Anyone know?
They probably negotiated a "permission to attack" before letting Strix off the leash, as pentesters usually do.
The fact that they don’t seem to explicitly state this fact but do go to lengths to explain how the agent didn’t do anything malicious while confirming how alive the token was makes me doubt they asked for permission to run the agent in the first place.
That's highly unlikely since it's standard practice in the industry, thus it's unnecessary to state it. Also, they didn't hack a hobby developer's website, but a prospective business partner who has enough money to sue them into oblivion. No way this wasn't announced.
Announcing that their agent restrained itself even though it got hold of a live token is necessary to convince prospective clients. You don't want a pentester that doesn't show this kind of reserve!
when t̶h̶e̶ ̶P̶r̶e̶s̶i̶d̶e̶n̶t̶ an AI company does it, that means that it is not illegal.
- AI Richard Nixon
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 of multiple repos (which is past what a name gives them), and they explicitly state: "A listing of that private repo showed a top-level customers/ directory, with subdirectory after subdirectory named after Baseten customers". Strix explicitly took action that they knew they were not permitted, and extracted confidential customer information. Claiming "We didn't clone the customer repo" when you, instead, just listed the contents of the repo, is not a valid defense.
Agreed. I suppose they'd have slightly less credibility by saying "we hacked <unnamed company>" but it strikes me as far classier than naming & shaming.
I'm not sure this is "naming and shaming" because I don't seen an intent to shame. They disclosed the vulnerability privately, waited months for patches, and were commended by the organization with the vulnerabilities.
There's no shame here, this was a mistake, probably made by a human, and ultimately corrected. Nobody seems upset by the outcome!
shaming people for bad security practices is probably net good, whether we like it or not
There is a big difference between "bad security practices" and "someone made a mistake 2.5 years ago"
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 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
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
How many ways will revert?
…by finding an admin token in logs.
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.
This wasn't GitHub's fault in any way.
Github personal access tokens are security footguns. This is an apparently old and forgotten image containing a token from 2023 and it the token gets you admin acces to their repos.
So many security breaches involve Linux in one way or another. Your argument doesn't really work.
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
Always check. I used a disk wiper , I checked the disk sectors, bang files under 1kb not really wiped...my "secrets" case..
It may make sense to change security practices so nothing has long term access. Everything should be rotated monthly, and maybe within a few years, hourly.
Running a one-person SaaS, the honest failure mode isn't "we decided not to rotate", it's "rotation isn't automated so it just never happens". A stale token from 2023 still being alive in 2026 says less about policy and more about nobody having a reason to touch that code path in three years.
For a small team the fix that actually sticks is having the platform expire things by default (short-lived tokens, forced re-issue) rather than relying on a human remembering to rotate on a calendar. That calendar reminder is competing with every other thing on a solo dev's plate, and it reliably loses.
I'd call Docker out on this. Why the hell is it recording
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.
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
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 :)
I wonder what model was used for this. Also as far as I know Baseten does not have any abliterated models in their repertoire.
It's odd personifying Strix as the thing that found these when it's whatever model they use doing the hard work.
Nobody says Claude Code hacked a company, it's Fable.
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.
The Chinese models talk Claudlish too
Hate to burst your bubble but wasn't Claude......
Chinese Claude distillation.
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 :)
Chinese? I can not imagine how a western state of the art model would follow through with such a task and not require some major trickery.
The writing sounds like Claude to me
> So Strix enumerated hosts, looked through certificate logs, mapped the full surface.
If there is anything that you should do while setting up infrastructure... it is getting rid of single-host SSL certificates. If you're on Amazon... just let it issue wildcard certificates and place an ALB in front of hosts that terminates the SSL connection. The very second a subdomain appears in any of the CT logs directly, you've lost, it will get hammered.
And keep your public and private Git, Docker, npm and whatnot registries separate infrastructure, with the private stuff only reachable from within the corporate network, preferably just servers. Too many a company got hacked and lost significant data because of someone exploiting a GitLab RCE on an instance that hosted both private and intentionally-public repositories. (Yes, I have been there.)
> It is their GitOps: the repository contains the desired state of the clusters, and it applies that state to the infrastructure.
That's another thing I frankly do not get why people are still doing it.
It's fine to have a Git pipeline do a lint, even a terraform plan using a read-only token (although that token needs access to the statefile aka s3 bucket... and there will be relevant secrets there). But, IMHO, a terraform apply should always, always be run on a machine of a sysadmin manually doing the apply. A human, you can hold accountable, and you can keep them at a good security posture with short-lived session tokens. But a Git pipeline where there is a cloud provider token with full admin permissions? That is one Gitlab RCE patch or Github issue away from being compromised.
Besides, one repository holding all the IaC stuff? That just sounds like hour long `terraform refresh` sessions.
> A human, you can hold accountable, and you can keep them at a good security posture with short-lived session tokens.
You can do this too (and better) with a repo: OIDC/Workload identity trust relationship between github and aws for short lived tokens + a github environment setup that requires manual approval. Bonus: It also gives you an audit trail with a github action log as opposed to a sysadmin running something on a laptop.
The problem here was mostly that they (for some reason) happened to use (and leak) a PAT.
The audit log for the sysadmin is in Cloudtrail, so nothing is lost there.
> Besides, one repository holding all the IaC stuff? That just sounds like hour long `terraform refresh` sessions.
If it is terraform, then typically it's split up into multiple "root modules" which get planned and applied separately, even though it's all in one repo.
cannot delete the card from billing.
> 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
Agreed. Pretty sure you are supposed to ask for permission before pentesting someone. Hopefully they, being a security company, know that.
A lawyers wet dream is when a security company.... Finds an issue, does not abuse it, and reports it to the affected party for it to be patched?
I feel like people like you are more of a lawyers wet dream, in that they'll happily litigate a frivolous case for you while billing you hourly.
Feelings don't really matter in the legal world. Statements and actions do.
And, most notably, intent.
https://www.justice.gov/archives/opa/pr/department-justice-a...
They did abuse if you read the article. They crossed a few lines.
if i find someones key on the ground and take the key and walk into their house and poke around, and make sure to leave a letter, this is a good thing?
The article reads like it was written by a child. I imagine their company is run the same way.
It should be illegal to produce software products that people will depend on and are this blatantly insecure
The part that matters more than the public Harbor project: the image was built in March 2023 and the token still worked when they found it in July 2026. Over three years. That is a classic PAT with no expiry, which GitHub still lets you create and which is still the easiest thing to reach for when you are wiring up a bot account.
Secret scanning would not have caught it either. It reads repositories, not image layers sitting in a registry on your own subdomain, so the coverage stopped exactly where the leak was.
Anton here from the baseten security team. I wanted to confirm that we collaborated with Strix on the remediation of the reported vulnerability. 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 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.
Box checking is an important business!
I can’t help noticing that an LLM can check boxes.
tokens yes, password rotation, no.
In 2017:
> NIST changed the guidance with SP 800-63B, published June 2017. It explicitly said:
"Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically)."
Instead, passwords should be changed when there is evidence they have been compromised, not every 30/60/90 days.
Unless github had regulated data, unlikely, the legal implications are few. Document the issue, remediate and no findings on the next audit. Done.
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.