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.

> 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

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.

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.

> [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.

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.

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.

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.

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

…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 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

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.

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?

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

I wonder what model was used for this. Also as far as I know Baseten does not have any abliterated models in their repertoire.

> 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.

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

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?

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.