Millions of AI agents imperiled by critical vulnerability in open source package
- Thread starter JournalBot
- Start date
Upvote
120
(140
/
-20)
Is it bad of me to have felt an acute rush of Schadenfreude over this?
The times create a certain amount of deviation in my moral compass lately so it's a kind of relevant question. Because that rush was huge.
Upvote
60
(80
/
-20)
It boggles my mind to see plumbing like Starlette routinely downloaded hundreds of thousands of times per week. I wonder what proportion of that is requests from GitHub continuous integration hosts endless downloading and then discarding the same version over and over.
Upvote
150
(152
/
-2)
I'm going to poo poo people here in the comments going "Ah it clearly must have been vibe coded" was it? Starlet and FastAPI aren't old, but they aren't "spring chickens" ... A lot of MCPs that got built in the last 2 or 3 years probably pull in FastAPI just because it was ... well very fast to build REST APIs with it. Was the bug introduced by vibe coding or just pre-existing and a ton of REST APIs to control or serve tools and content for LLMs just happen to use it?
Upvote
147
(149
/
-2)
Two things that are true:
1) FastAPI is an extremely useful and popular python library that depends on Starlette
2) Codebases requiring FastAPI/ASGI can be for stuff that doesn't have anything to do with AI/LLMs or vibe coding.
The "oh_no_anyway.gif" comments are annoying and misplaced given this context, so maybe hold your fire on this one. I will be the first to agree that the slop-machines are very bad for all of us, but I would also say it's better to opine on the thoughts produced by XKCD's "Dependency" comic instead of rushing to performatively denigrate AI stuff just because this one package is used in concert with it.
Upvote
188
(193
/
-5)
I'd put it as "Millions of AI agents and tools ARE a critical vulnerability..." but maybe that's just me.
Upvote
19
(30
/
-11)
Can we please not make this a thing, Ars? Whenever a vulnerability comes up that has some sort of usage relating to AI, can we please not frame articles like "AI" the monolith is somehow solely responsible ?
This article - mostly the headline is clearly getting the users who don't understand what the dependencies are or how they can be utilized in a tizzy. This becoming a cliche...
This article - mostly the headline is clearly getting the users who don't understand what the dependencies are or how they can be utilized in a tizzy. This becoming a cliche...
Last edited:
Upvote
40
(62
/
-22)
I don't think "clearly must be", but at the same time "do the same basic thing two different ways within the same context for no obvious reason" is a thing that LLMs seem to routinely do.
Upvote
-8
(6
/
-14)
Fair. Is that what happened here? I think this is just a pre-existing, old-fashioned human made vuln, and its just a very popular package that provides the very necessary plumbing for basically any kind of MCP or even simple CRUD App integrated with an LLM. The relationship is casual, not causal.
Upvote
64
(64
/
0)
If so, then me too. I had a Nelson "Ha, ha" moment when I read the title. And it doubled down when I read the article. This DOES appear to be a very trivial to exploit, and should have been easy to discover before deployment, security hole.
And I can't help reading stuff about LLMs and "AI" agents and always thinking "move fast, break things, fix nothing, make nothing better".
Upvote
-18
(6
/
-24)
Here's one technical description of the vulnerability.
It's rather simple: instead of sticking
It's rather simple: instead of sticking
example.com into the host header, Starlette lets you also put things like example.com/abc?bar= in there, which turns a fetch of /foo from example.com into a fetch of http://example.com/abc?bar=/foo.
Upvote
59
(59
/
0)
Nothing here says vibe coded. It looks like a rather old school “two ways to interpret this” bug. I feel like there should be a better description than that.
Upvote
51
(51
/
0)
It’s also a thing lots of humans do too, when they’re naive young programmers without proper code review, or just not seeing the whole picture.
Edit to add: who hasn’t see cut and paste from stack overflow cause something like this?
Upvote
22
(22
/
0)
So I mean the criticisms is on Starlette then? Like not to anthropomorphize these things, because its cringe, but are you red teaming every package, especially popular packages, you're pip installing? I'm not going to go so far as to criticize Ars for editorializing the title a bit but this exact same vuln would have been bad regardless of whether a lot of AI tooling was built on top of it. If this happened in flask, which is very popular still, but seems to not be the framework most LLMs reach for to build a REST API or MCP, it would still be very bad.
Last edited:
Upvote
19
(21
/
-2)
I'm trying really hard to figure out why people think this vuln has anything to do with vibe coding or AI (aside from a lot of AI frameworks build on top of it — because it is simple and fast)
My website is written in FastAPI/Starlette (no auth, no problem). It's just a very popular framework.
My website is written in FastAPI/Starlette (no auth, no problem). It's just a very popular framework.
Upvote
74
(74
/
0)
I think if ars wants to avoid their own version of enshitification they should probably knock off the titles catering to the self proclaimed "luddite" tech poseur. It won't age well and it's sort of dishonest and agenda driven. In this case it's blatant reaching to everyone who has experience with these dependencies... And there are quite a few of us reading ars.
Upvote
-1
(19
/
-20)
From a quick look at the change made in the fixed version (1.0.1) and blame on the affected file, it looks like Starlette has been trusting the host header like this for 8 years - i.e. since it was first released.
As this article points out, it's one layer in the tech stack assuming that other layers are doing the right thing and not defensively coding.
As this article points out, it's one layer in the tech stack assuming that other layers are doing the right thing and not defensively coding.
Upvote
53
(53
/
0)
And when we see evidence this is the result of that then it will be relevant, but that's not how this article was framed.
This should have been an article catering to developers and sys admins informing us of a vulnerability. Instead it's yet another cliche anti AI article that's reaching to cater to a crowd of people who click on anything that relates to what outrages them. It's dishonest and the result is confusion and confirmation bias for those without the skill or authority to understand this isn't even about AI. It's agenda driven click bait crap and I'm concerned about this websites standards for reporting and writing.
Upvote
12
(22
/
-10)
We use FastAPI a lot (because of their built in OpenAPI integration) - we are working overtime to make sure everything is secure. AI agentic usecases are the smallest affected market in this as far as I can tell.
Upvote
31
(31
/
0)
I'd very much love to join you all in dunking on AI but Starlette is used by many things non-AI and this is a pretty shitty vulnerability.
Upvote
27
(28
/
-1)
This may be more a function of the fact that Python is popular with the AI crowd.
Up until now Python has been more deeply embedded behind API Gateways that are likely to insulate the code from the internet. These gateways are likely built on top of battle tested platforms like NGNX, Apache, Netty and Spring Frameworks.
Pushing Python out in front means now its frameworks like FastAPI (Or Starlette's) turn to get pounded on until all the different ways of attacking open HTTP servers have been dealt with?
Upvote
11
(14
/
-3)
and the security-lax move-fast-and-data-mine the shit out of your customers automotive industry.
Upvote
-9
(1
/
-10)
I’m really disappointed in the spin Dan chose for this article. While it’s true that some AI code uses this, tons of purely-human authored code has it as well.
Upvote
42
(43
/
-1)
just ask the hackers, I mean, the researchers.
they dont care. it's still a basic ssrf that a human should have known was possible. its not even an injection prompt vuln.
Upvote
-1
(0
/
-1)
Aside from the "why is this article about AI when it's actually a real problem affecting real web servers that competent people use", is it that hard to explain the actual issue? This paragraph from the disclosure explains it perfectly:
(For less technical folks, a quick summary is that HTTP sends the hostname and path separately; e.g., www.example.com and /articles/thisone. But then they're combined and reparsed, so if you send a hostname of example.com/route and a path of /more, the framework will incorrectly pass it along as a host of example.com and a path of route/more.)
Remind me again why I bother reading security articles on ars instead of a mainstream newspaper? The quality seems to be converging, and not in the way I like.
(For less technical folks, a quick summary is that HTTP sends the hostname and path separately; e.g., www.example.com and /articles/thisone. But then they're combined and reparsed, so if you send a hostname of example.com/route and a path of /more, the framework will incorrectly pass it along as a host of example.com and a path of route/more.)
Upvote
31
(33
/
-2)
Upvote
-15
(1
/
-16)