Where Convenience Forgot to Lock the Door

Somewhere in the UK, on a machine that doesn't actually run anything real, a set of honeypots have spent September answering to a name they don't own. They call themselves Langflow instances, the open-source, drag-and-drop platform that lets anyone wire together language models, vector databases, and custom logic into something that looks like a finished AI product. The honeypots aren't real. The traffic hitting them is. Since late August, researchers watching those decoys have logged wave after wave of requests, most of them originating out of Russia, all of them asking the same handful of questions: what's your OpenAI key. What's your AWS secret. What's in your .bash_history. Who are you, really, and what do you have that's worth taking.

That's CVE-2026–0768: a Python code execution bug living inside Langflow's validate endpoint, the part of the app meant to let a developer test a snippet of code before wiring it into an agent. Someone forgot to ask whether that code needed to come from someone the app actually trusted. So it doesn't. Anyone can send Langflow a string, and Langflow, helpfully and faithfully, will run it. As root, on versions up through 1.4.2, with no login required. It scores a 9.8 out of 10 on the severity scale most of the industry agrees to use, which is about as close as CVSS gets to this one goes to eleven.

I want to be careful with how I write about this one, because it isn't really new. That's the part that should unsettle you more than the CVE number does.

A door with the lock missing, again

Langflow has had this exact conversation before. Back in 2025, a different bug lived in that same validate endpoint (CVE-2025–3248), and it got fixed the honest way: the team ripped out the Python exec() call the endpoint had relied on and replaced it with something that only compiles code instead of running it. Compiling isn't running. That was the whole point.

Four months after that fix shipped, unsafe execution found its way back into the exact same corner of the app. Not the identical bug, but a sibling of it: patient, familiar, wearing a new CVE number. Whether that's an incomplete fix, a merge that reverted the safe version, or a reintroduced feature nobody flagged as dangerous the second time around, the lesson is one every red teamer eventually learns and every blue teamer eventually has to accept. A patched vulnerability class is not a closed vulnerability class. It's a chalk outline. Something else will stand in that exact spot again if nobody's watching the spot itself.

Langflow isn't an outlier being unfairly singled out. It's just the visible case. Researchers have tracked twelve separate exploited vulnerabilities across the platform in a single year, compared to just one before 2026 even started. More than 15,000 successful exploitation attempts, spread across a cluster of related flaws, have hit instances someone decided were fine to leave facing the open internet. Ollama has had its own incidents this year. So has Gradio. So has Open WebUI. That's not a coincidence so much as a pattern repeating itself across an entire category of software.

Why the "soft" in soft target isn't an insult

Here's the thing that took me longer than it should have to internalize: these frameworks aren't badly built because the people building them are careless. They're badly secured because they were built for a different job than the one they're doing now.

Langflow was never pitched as a production security boundary. It was pitched as a canvas: drag a language model here, connect it to a vector store there, wire in a custom Python snippet to glue the two together, and watch your agent come alive in the browser. That's a useful thing to build, and the validate endpoint now bleeding API keys across the internet exists for a reasonable reason: developers need to test code before they commit it to a workflow. The real problem is that "lets you run code" and "is reachable by anyone with a browser" ended up living in the same sentence, and nobody drew a hard enough line between them before it shipped.

That's the pattern across almost every AI framework getting popped right now. The interesting thing these tools do (orchestrate models, chain tools together, execute code on an agent's behalf, hold the credentials that let an agent act in the world) is also, structurally, the exact thing an attacker wants. You can't cleanly separate "the feature" from "the vulnerability class" the way you can in an ordinary CRUD app, because the feature is code execution with elevated trust. Traditional web apps mostly try to keep users from doing more than they're supposed to. Agent frameworks are built around the premise that the software itself should be allowed to do quite a lot, and then assume that whoever's talking to it deserves to inherit all of it.

What actually changes when you go hunting here

If you've spent time doing recon against ordinary web apps (mapping endpoints, fuzzing parameters, poking at auth boundaries), some of that muscle memory transfers cleanly to AI-agent-serving apps. Most of it doesn't, or at least not in the order you're used to using it.

Internal tooling endpoints stop being low priority. The instinct in classic web recon is to focus on the parts of an app clearly meant for the public: login, checkout, search. In an agent framework, the endpoint worth your time is often the one that looks like leftover developer convenience, something like a /validate, a /test, a /preview, a /debug route that was never meant to face the internet and does anyway. Those routes get built fast, under the assumption that whoever hits them is trusted by default, because in the original design, they were. Then the whole thing gets containerized and shipped, and the assumption doesn't survive the trip.

The default assumption about where the power sits needs to flip. In a normal app, an unauthenticated user usually has the least capability in the system, and you're hunting for the crack that lets them climb. In an agent framework, the unauthenticated surface sometimes holds more raw power than the authenticated one, because "authenticated" was built for people managing agents, while the exposed parts were built to let code run, period. Don't assume the front door is the weakest one. Check whether the side door someone left for developers was ever meant to have a lock at all.

The credential trail matters more than the shell. Getting code execution on one of these platforms is rarely the finish line. It's the entry fee. The real prize behind Langflow's RCE isn't control of a container, it's every secret that container was trusted to hold: model provider tokens, cloud access keys, database strings, the platform's own signing key. When you're testing with authorization, map what a successful execution actually reaches: the environment variables, the cache directories, the config files a well-behaved agent framework tends to keep close by. That's where the real severity of a finding lives, not in the exec() call itself.

The dependency graph is part of the attack surface. These frameworks don't stand alone. They pull in vector databases, orchestration libraries, model SDKs, and the CI pipelines that build and ship the thing. An unpinned package or a loosely trusted build action deep in that tree is a real way in, and it's a habit classic web testing sometimes skips past, since it doesn't live inside the app's own request and response cycle.

The line between text and instruction is worth watching closely. This one has no clean analogue in traditional web testing. Every agent framework has to decide, somewhere in its code, whether a piece of user-supplied text is data to be stored and displayed, or an instruction to be acted on. Prompt injection lives exactly in the seams where that decision gets made carelessly, and unlike classic injection bugs, there's no universally agreed escaping strategy yet. That ambiguity is itself the attack surface.

None of this replaces the fundamentals. You still map, still fuzz, still read source when it's open, still respect scope. But the target has changed shape, and the shape it's changed into rewards curiosity about what this software was actually built to trust, more than curiosity about what it was built to display.

The part I keep coming back to

Before this year, Langflow had exactly one exploited vulnerability in its history. Now it has twelve. That's not a story about one careless team. It's a story about an entire category of software racing from prototype to production faster than its security model can keep up, and about how many of these tools are sitting on the open internet right now, holding the keys to everything they're connected to, because nobody drew the line between "convenient for the developer" and "safe for the internet" before it mattered.

If you build with these frameworks, assume the endpoint you never think about is the one worth thinking about. If you break things for a living, this is where the interesting bugs are going to live for the next few years: not in the login form, but in the seams where "AI app" became "arbitrary code execution as a service."

I'll be writing more of these as I find them: the disclosures worth slowing down for, and what they actually mean for the people building and breaking this stuff. If that's useful to you, stick around.