Last month I did the thing you're supposed to do and hate doing: I went through my own homelab hunting for the stuff I'd stood up "just to try" and never came back to. A vector DB here. A workflow builder there. An LLM gateway I'd exposed to the LAN for ten minutes to test something and never un-exposed. None of it was load-bearing. All of it was still running. And more of it was reachable than I wanted to admit.
That is the honest story of how AI tooling got deployed everywhere in 2025. Not through an architecture review. Through "I need to demo a flow to a stakeholder by Friday." The tool that best captures what happens next is Langflow -- which is exactly why it's the one currently getting hammered.
The 20-hour clock
On March 17, the advisory for CVE-2026-33017 went out. No proof-of-concept attached. By the next morning, Sysdig's honeypots were watching automated scanners sweep for exposed instances, and shortly after that an attacker was inside one of the decoys running:
env
find /app -name "*.db" -o -name "*.env"
Roughly twenty hours from a disclosure that shipped no exploit code to working exploitation in the wild. The attackers built the exploit from the advisory text alone. CISA added it to the Known Exploited Vulnerabilities catalog on March 25 with an April 8 federal deadline.
The bug itself is about as clean as RCE gets. Langflow exposes an endpoint whose whole job is building "public flows," so it's intentionally unauthenticated:
POST /api/v1/build_public_tmp/{flow_id}/flow
The intent was that it would build from a flow definition already stored server-side. What it did, in every release before 1.9.0, was accept attacker-supplied flow data -- Python embedded in the node definitions -- and pass it straight to exec() with no sandbox. One request, no credentials, arbitrary code on the host.
The framework is the target, not the box
Here's the part that should bother you more than the RCE, and it's the reason this whole category is worth a post instead of a patch note.
An orchestration framework is a credential concentrator.
Langflow flows embed provider keys, cloud credentials, and database strings directly in their component configs, because that's how a flow talks to OpenAI or Anthropic or your Postgres box. So code execution on the host doesn't win the attacker compute. It wins them the pile of keys sitting in the environment, and those keys are liquid -- resellable, or immediately abusable to run up a bill on your account.
You don't have to infer the motive. In a later Langflow incident, Sysdig watched an operator hijack a flow and feed it the prompt leak api keys, coaxing a flow that ran with its own embedded credentials into handing them over. That's the whole game in three words.
It's not one bug, and it's not one framework
CVE-2026-33017 isn't the only door. CVE-2026-5027 is a path traversal in Langflow's file-upload endpoint that lets an attacker write a file to an arbitrary location -- into /etc/cron.d, permissions allowing, and the next cron run is a shell. Its CVSS vector formally requires low privileges, but Langflow ships with auto-login on by default, which hands an exposed instance a session token on request, so on the deployments that got hit the credential barrier was cosmetic. Tenable disclosed it March 27. In-the-wild exploitation showed up in June. More than two months in which every unpatched instance sat open.
And patching turned out to be its own trap. JFrog empirically tested the version widely reported as fixed -- 1.8.2 -- and found it still exploitable. Their point was blunt and correct: you don't know something is patched by reading a release note, only by checking how the code behaves. The maintainers fixed the affected-version range quickly once told, but for a window the version everyone believed was safe wasn't.
Then it stops being a Langflow story. LangChain-core has a path traversal in its legacy prompt-loading API that can read local config and secret-bearing files off disk. LangGraph carries an insecure-deserialization chain in its SQLite and Redis checkpoint stores that Check Point walked from SQL injection to code execution in self-hosted deployments; managed LangSmith wasn't affected. Neither has confirmed in-the-wild exploitation yet, and Check Point ships working proof-of-concept, so "yet" is carrying its weight.
These are the same bug classes -- injection, traversal, deserialization -- we've been writing for decades. Merritt Baer, former deputy CISO at AWS, named why they're hard to see coming here: when it lands, "it will feel like your traditional security program failing" rather than an AI problem. The exploit lives three layers down in a framework your code imports. Your WAF never inspects the deserializer. Your EDR waves through the process calls the agent server makes a thousand times a day.
What this does NOT solve
This is the part I care most about getting right, because the fixes below are real but they are not a clean win, and pretending otherwise is how you end up surprised twice.
- Patching now doesn't un-leak what already leaked. If your instance sat exposed during any of these windows, the keys may already be gone. Rotation is damage control, not prevention.
- It doesn't find your shadow deployments. The Langflow you know about isn't the problem -- it's the one someone spun up in a forgotten project. Patching is downstream of discovery, and discovery is the part almost nobody is actually doing.
- It doesn't touch the LangGraph/LangChain class. Patching Langflow does nothing for a deserialization chain sitting in your agent's checkpoint store. Different frameworks, same shape, separate patches.
- It doesn't fix the upstream pattern. The incentive is still ship-fast, and OSS security response in this corner is still immature -- two-plus months from a Tenable report to vendor acknowledgment in one case. The next low-code AI framework will arrive with the same weaknesses.
- Runtime detection only catches the loud attacker. The scripted miner that spawns a shell is easy. The patient operator who lands, reads exactly one
.env, and leaves is a different problem, and something will wave them through.
What to actually do anyway
None of this is exotic. In rough priority:
- Get it off the public internet. There's almost no legitimate reason a Langflow or LangGraph instance should answer to the open web. Auth or a VPN in front, full stop.
- Patch to current, then verify the patch closed the hole. Don't trust the changelog -- JFrog already caught one "fixed" release that wasn't. Check the commit or run the PoC.
- Rotate every credential the instance could reach. Provider keys, cloud creds, DB strings. If it was exposed, assume they walked.
- Give each deployment an owner inside the same external attack-surface monitoring as the rest of production. You can't patch what you don't know you're running.
- Add runtime detection that needs no signature. Falco will flag a web process spawning a shell or reading
.env on day zero, before anyone's written a rule for the specific CVE.
The uncomfortable part was never a single CVE. We spent a year handing every team a low-code button that stands up an internet-reachable Python execution environment holding a wallet of API keys, told them to move fast, and never wired those deployments into the security program governing everything else we run. The frameworks did what they were built to do. The bugs are the ones we've always had. What's new is where they live and what they're standing next to.
Your turn
Here's what I actually want to know, because I don't think anyone has a clean answer yet. Is anyone treating AI orchestration tooling as a first-class asset in their attack-surface program, or is it all still shadow deployments and good intentions? If you run Langflow, LangGraph, or anything in that family in production -- who owns the patch cycle, honestly? And has anyone found a discovery method that surfaces these before an attacker's scanner does? I'd rather learn your approach than keep guessing at mine.
Originally published at blog.vertexops.org.
