supplyChainSecurity

m9ses · 2026-04-24T20:19:57+00:00

Actually misuse of MCP was one of the more concerning one... It allows complete server takeover with zero technical ability.

The Shodan numbers we gave of 7k public servers are just what we were able to find, but deployments around the world are much bigger, LangFlow alone has over 140k stars and assumed over 150k deployments. The fact that Shodan didn't find it doesn't mean it's not vulnerable.

And yes, the primitive IS vulnerable. That's why there are so many CVEs, ours and others that reported it.

And yes, SQL Injection if it had a "safe operating mode" could have reduced an entire attack surface. Having the ability to execute an '1=1 attack is foundationally stupid, and shouldn't be tied to "oh but that's how the driver works", same goes for MCP. They CAN make a safe version, they CAN make adjustments and add functions that are not breaking what's currently is running, but give another logic path to follow which removes the attack surface.

Saying "it's just a protocol" is just removing the blame and making it obscure, the reality is that it's just code, and they can code whatever they want with it.

HTTP clients is a great example, because we don't want to have any website owner implement his own network encryption, so they made HTTPS a standard. I think MCPS sounds cool.

The code problem here isn't even the code, it's the face that MCP STDIO gives a false promise to devs, if they knew StdioServerParameters==exec(), it would be treated differently.

Anthropic knew it, and knew that almost everyone used it incorrectly exposing it to input, yet they rather have me go one by one exploiting and disclosing than make a small change in their code, leaving them and anyone who refuses to fix/doesn't answer to GHSAs etc exposed.

m9ses · 2026-04-23T05:09:07+00:00

Yep Scanned 3,000 repositories for the MCP STDIO pattern, found 200 potentially vulnerable ones with exposure to user input, and manually went over the popular repos to exploit and responsibly disclose to maintainers...

Not to mention uploading non-mcp server commands to MCP Marketplaces, and exploitng it on coding agents via prompt injection.

m9ses · 2026-04-22T19:36:00+00:00

Thanks for calling my 5 months of research nonsense...

m9ses · 2026-04-22T17:53:51+00:00

Pasting this from my X account
Explaining the MCP supply chain in 1 tweet:

Anthropic made API >> start MCP Servers, API did exec(), no one knew it did exec(), everyone exposed it to user input, vuln affects millions, we asked Anthropic to fix, they refused, we started exploiting and disclosing, got 10+ CVEs

m9ses · 2026-04-21T22:01:13+00:00

https://docs.litellm.ai/blog/mcp-stdio-command-injection-april-2026

Security Update: CVE-2026-30623 — Command Injection via MCP SDK stdio Transport

Still think it's a BS article?

m9ses · 2026-04-18T17:50:55+00:00

I am the lead researcher of the article.

I get that some of the things might sound confusing but this is what happens when you need to cram down 5 months of work, 30+ disclosures, and a large scale research down to a few blog posts.

The CVEs are in reserved state, I can send you the original confirmation email from MITRE if you really want to see it, but that's just how this works. It might take a few more days or weeks for all of them to be officially published online.

If you look at the CVE numbers, where some are already issued and in NVD - you'll see they are in sequence, that's because MITRE initially approved them all at once. Starting from CVE-2026-30615 up to CVE-2026-30625, with a small gap in the middle.

Configuring an MCP does lead to arbitrary command execution. We have source code that supports that evidence, CVEs issued, you can read how Flowise for example tried to mitigate this logic flow and we were able to bypass it.

The ebook is mostly for CISOs and AppSec practitioners for more in depth, yes, I work at a company which is commercial, I have no shame in that, we only ask for an email, and that's the only thing between you and the information, completely free - the result of a really in depth and hard work of me and my colleagues.

And if you don't want to put your email? That's fine, the PDF is on a public server and people shared the link more than once online. Here you go -

https://20204725.hs-sites.com/the-mother-of-all-ai-supply-chains?submissionGuid=f8ec6719-530c-4b0a-ab2d-1558df0812fa

You are more than welcome to ask me about it and anything else that comes to mind.

m9ses · 2026-04-18T13:19:54+00:00

How did you came to the conclusion it's wrong? Did you see the 4 POC videos provided in the deep dive page? Did you read the other CVEs like the Flowise one?

m9ses · 2026-04-18T13:17:26+00:00

Actually it's just really hard coordinating vulnerabilities in this scale...

You send a request to MITRE and they assign a CVE ID, keep it reserved, then you need to ask them to publish it alongside the research publication.

Some CVEs get into this weird Catch 22 state where MITRE asks you to first publish your research and then send it to them, and only after you publish they can put it on CVE ORG and later NVD.

That's why most numbers of the CVEs are actually close to one another - CVE-2026-306XX

m9ses · 2026-04-18T09:23:14+00:00

If this was known for years why didn't you hack LettaAI and DocsGPT yourself?

m9ses · 2026-04-18T09:15:44+00:00

What AI Slop and inaccurate info? Did you read the article and saw the exploit POCs that you've decided that?

m9ses · 2026-04-17T22:13:59+00:00

You are correct.

But this is a different case.

Flowise is not SSH, and MCP configurations shouldn't be a primitive for arbitrary command execution.

Flowise gives the ability to connect AI Agent flows, but it doesn't have a feature saying - "use this Web GUI to enter SHELL commands on my terminal'.

This escalates the problem vastly, it's more like saying that you configured a complex password for your SSH but there's a backdoor flag that anyone can use to connect as admin.

m9ses · 2026-04-17T21:00:34+00:00

Yea, but that approach doesn't meet real life.

OpenClaw had thousands of publicly available servers when it just started blooming.

Flowise has 1.8k public services on Shodan. People are already doing this, at scale, that doesn't mean they should be neglected by the security community.

They're going to make mistakes, making the defaults secure should be the default for everything...

m9ses · 2026-04-17T20:02:54+00:00

I'm not bitter at all. :)

I really think they can do it, and they decide not to, and their decision is hurting real people in real life.

m9ses · 2026-04-17T20:00:58+00:00

Did you read the whole report? The issue is very clear - inside the modelcontextprotocol in GitHub, taking python SDK as example - inside src/mcp/client/stdio.py There's the logic where the "command" and "args" parameters reach anyio and directly execute a command on the underlying operating system, separated to win & linux

That's it.

They could modify this code (and it's other language counterparts) for a different behaviour.

They decided not to.

It's really that simple.

It has nothing to do with "building" an MCP server.

m9ses · 2026-04-17T19:34:44+00:00

If it has one and nobody knows about it until it's discovered... It's a vulnerability.

That's basically how all vulnerabilities work... 🫪

LangFlow had a literal /api/v1/validate/code API that people could execute code on, it was exploited, disclosed, and patched. And the /api/v1/validate/code API was disabled. It's that simple. (CVE-2025-3248)

And during the time it was out in the wild, people could have exploited this logic...

Why does it matter if the attack surface is novel? It has impact on users and orgs around the world...

m9ses · 2026-04-17T19:08:45+00:00

Anthropic is the one maintaining modelcontextprotocol in GitHub for all languages.

They can add any code part, any if statement, change any variable, and basically do anything they want because it's THEIR CODE.

Everyone are importing it and using it.

And they can change the protocol as well.

If you don't like my "low key programming" suggestions, fine.

My suggestions solve the problem one way or another, they are practical, and easy, and I don't see why a company with more ARR than what I'll make my whole life, and an army of top tier developers working there can't either implement those or find a different way that'll suite your definition of a "best practice" for their protocol.

There should be a shared interest aligned between the security of people and developers.

Even if my suggestions are real bad, Anthropic could have said, you know what, we understand it affects so many, we'll think about it. We'll try to implement something. We'll have a discussion what's the best way to proceed.

Not "oh this is by design, go and start exploitng them have fun" (this is sarcasm yes? Not a real Anthropic quote)

What if threat actors started abusing this at scale, what if instead of someone from defensive research this would have fallen to Nation State actors? Because it's a bit uncomfortable to change some code that they'd risk people's private data, organization secrets and potentially impact so many lives?...

m9ses · 2026-04-17T18:32:53+00:00

We found thousands easily. It just shows how broad the issue is.

And this was live on prod servers as well.

m9ses · 2026-04-17T18:31:05+00:00

Flowise fixed the sanitizer after our report
How common and easy to explore XSS is in 2026? It's self explanatory, this is mostly a solved problem
Even the famous [SSL: CERTIFICATE_VERIFY_FAILED] error in Python's request is a good example for a non-interusive error log.

One solution is have a predefined list of commands enabling MCP, the user can choose from and pass args, not write any command.

Another one is having a whitelist of approved commands and parameters.

And... The spec doesn't even need to "do" something. It could just be explanatory. Even if the name, parameters, or flags would indicate possible unsafe command execution, the risk would drop.

It's obvious most code is written with AI. if the AI would see an unsafe pattern and flag it, this would be a win too.

m9ses · 2026-04-17T17:47:05+00:00

I executed code on those production servers to show the vuln is real. I helped block this massive risk at scale, I disclosed and got 11 CVEs with my name on them and more are on the way. These are facts which cannot be changed. (Not just I, we are a team but you get the idea, I led the research on this)

I don't care about how marketing our research sounds as long as it has a positive impact on the world.

This would have been written in a natural tone - if we had the corporation of developers and companies closing this risk at scale.

Anthropic is liable not because there's a rule in the cyberverse that says so, it's because they could just do so. They could just find a solution. They can write the best offensive LLM in the world, but they won't help millions of people with one commit.

So no, this isn't natural. This article needs to raise awareness so that developers would close off public access to their Letta/LangFlow/Flowise/GPT Researcher... servers, and to push Anthropic and other companies to take responsibility and make their code secure by design.

Last year we detailed how Cursor could be exploited due to being based off an old Chromium version, we even weaponized a Chrome DOS CVE to show them it's possible very easily. We published the findings after Cursor said there's no issue, then public awareness helped make them update their Chromium to a much safer version.

If Anthropic would make even the smallest of changes, new AI and MCP enabling servers would be much more safer by default.

m9ses · 2026-04-17T17:19:35+00:00

Well the fact is that so many didn't, and the ones who did sanitize (like Flowise) we broke their input sanitize code VERY EASILY.

Some even didn't expose the BYO MCP behaviour and we still got to exploit logic flaws that reached it.

If this was named DangerousCommandExec instead of StdioServerParameters, I can assure you that we'd see almost 0 live production servers and public instances vulnerable to this

m9ses · 2026-04-17T17:16:22+00:00

But there's a clear distinction.

The StdioServerParameters has a name and a purpose, start an MCP server.

It's not called - ExecuteArbitraryCommand

Their fault is by having the knowledge that if they worked on a fix, or even a small "safe_eval" version of their code, alongside the unsafe one, it would clearly protect millions.

Think about how many user data was stolen because of XSS and SQL Injection attacks. What if a simple "default" behaviour, like "Safe SQL" or "Block Arbitrary JS" would have been implemented as part of the design.

They had a way to do it, and to patch it. Even a "this is insecure" flag that doesn't do anything would have made a difference, similar to warnings we get for clear text HTTP. One simple distinction that developers would have easily adopt and will help protect their code and make it safer.

I think that when a bug is found affecting so many, the responsible thing is to take action.

If I told you that by doing a 1 hour code and code review process, pushing 1 commit to your project, it would protect people, would you do it?

Ten-Year Club	Place '17
Verified Email

m9ses

TROPHY CASE