Langflow Got Owned in 20 Hours

Two days ago, CISA added CVE-2026-33017 to its Known Exploited Vulnerabilities catalog. The affected software is Langflow, the open-source drag-and-drop tool that tens of thousands of developers use to build AI agents and RAG pipelines. The vulnerability is an unauthenticated remote code execution — a single HTTP POST request gives an attacker full control of the server.

That alone would be worth writing about. But what makes this story worth your time is the timeline: attackers built working exploits and started hitting internet-facing Langflow instances twenty hours after the advisory was published. No public proof-of-concept existed yet. They reverse-engineered the exploit from the advisory text alone.

And the patch that was supposed to fix it? It didn't.

What Langflow Is and Why People Run It

Langflow is a visual framework for building AI workflows. Think of it as a drag-and-drop canvas where you wire together LLM calls, vector databases, API integrations, and custom logic into pipelines. It sits on top of LangChain and has exploded in popularity — the GitHub repo has over 50,000 stars, and DataStax acquired the project to offer a managed cloud version.

People use it to prototype chatbots, build question-answering systems, connect AI models to internal tools, and create autonomous agents. It's the kind of tool that a development team spins up to prove out an idea, and then — more often than anyone wants to admit — quietly becomes part of production infrastructure.

Censys found 1,156 Langflow servers exposed to the internet. About 360 of them appeared to be running vulnerable versions. Those are just the ones visible from the outside.

The Vulnerability: Unsandboxed Code Evaluation

The root cause is painfully familiar to anyone who's followed web application security: user-controlled input gets passed directly to Python's code evaluation functions with no sandboxing.

Langflow has an endpoint — /api/v1/build_public_tmp/{flow_id}/flow — designed to let unauthenticated users build public flows. When you send a request to this endpoint with a data parameter, Langflow uses your data instead of the stored flow data from its database. That data includes node definitions, which contain code. That code gets extracted, compiled, and evaluated with no restrictions.

No sandbox. No AST filtering. No restrictions on imports. The malicious code runs at the validation layer, before the actual workflow even starts.

The attack requirements are minimal. The target needs at least one public flow, and the attacker needs to know its UUID. But here's the kicker: Langflow ships with AUTO_LOGIN=true by default. With auto-login enabled, an unauthenticated attacker can hit GET /api/v1/auto_login, get a superuser token, create their own public flow, and then exploit it. The whole chain requires nothing but network access to the Langflow instance.

As Sysdig's threat research team put it: the attack requires a single HTTP POST request with a JSON payload — no multi-step chains, no session management, no CSRF tokens.

Twenty Hours From Advisory to Exploitation

Sysdig's researchers tracked the exploitation timeline in detail, and it reads like a countdown.

Hour zero (March 17, 20:05 UTC): The security advisory goes public.

Hour twenty (March 18, 16:04 UTC): First exploitation attempt observed. Automated scanners using nuclei templates start probing Langflow instances from four different IP addresses, all using identical interactsh callbacks to detect vulnerable targets.

Hour twenty-one: Custom Python exploit scripts appear. These aren't script-kiddie tools — they perform staged reconnaissance, fingerprinting the target before delivering payloads.

Hour twenty-four to thirty: Sophisticated credential harvesting begins. Attackers start exfiltrating environment variables and configuration files from compromised instances.

No public proof-of-concept was available during any of this. The attackers read the advisory, understood the vulnerable code path, and wrote working exploits from scratch. This is the reality of vulnerability disclosure in 2026 — the median time-to-exploit has collapsed from over two years in 2018 to hours.

What Attackers Were Stealing

The payloads Sysdig observed were simple and focused: run a system command, base64-encode the output, and send it to an attacker-controlled callback URL. Straightforward, but effective.

What the attackers were exfiltrating tells you what Langflow environments typically contain:

• API keys for OpenAI, Anthropic, and AWS — many with unrestricted spend limits
• Cloud authentication tokens that enable lateral movement into other services
• Database connection strings with access to stored flow data and vector embeddings
• Configuration files — .env files packed with internal service URLs and deployment secrets
• System files like /etc/passwd and directory listings for further reconnaissance

If you're running an AI workflow tool, think about what's in its environment. The LLM API keys alone could run up a five-figure bill in a day if an attacker decides to use them for their own purposes. The cloud credentials are worse — they're a foothold into everything else.

The Patch That Wasn't

This is where the story gets ugly.

Langflow released version 1.8.2, which the changelog described as a fix to "prevent RCE via data parameter in build_public_tmp endpoint." The National Vulnerability Database listed only versions below 1.8.2 as vulnerable. GitHub's advisory system flagged 1.8.2 as patched. Multiple security news outlets reported 1.8.2 as the fix.

JFrog's security research team decided to verify. They ran the public proof-of-concept against Langflow 1.8.2, both the PyPI installation and the Docker image. The exploit worked on both. Version 1.8.2 was not fixed.

The maintainer's own GitHub advisory actually stated that only "1.9.0 and above" were patched, but this contradicted what the NVD and changelog said. If you were a sysadmin who checked the NVD, saw that 1.8.2 was the fix, updated, and moved on — you were still vulnerable.

The actual fix is in version 1.9.0. If you can't update to 1.9.0 immediately, there's also langflow-nightly version 1.9.0.dev18, which JFrog confirmed blocks the exploit. But 1.8.2 is not safe.

This kind of confusion around patches is a nightmare scenario. Organizations that did the right thing — tracked the advisory, applied what they believed was the fix — were left exposed. It erodes trust in the entire vulnerability disclosure and patching process.

Same Bug, Second Time Around

Here's the part that should really bother you: this isn't Langflow's first code evaluation vulnerability.

CVE-2025-3248, disclosed in May 2025, was a CVSS 9.8 RCE affecting a different endpoint (/api/v1/validate/code) that used the same dangerous pattern of evaluating user-supplied code without restrictions. Langflow's fix for that one was to add authentication to the vulnerable endpoint. They didn't address the underlying problem — that arbitrary code gets evaluated without sandboxing.

Ten months later, a different endpoint with the same dangerous pattern was found. Same root cause: unrestricted code evaluation, no sandboxing, unrestricted dynamic imports. The first CVE was also added to CISA's KEV catalog. So this is the second time CISA has flagged Langflow for a critical, actively-exploited code evaluation vulnerability.

When you fix a symptom instead of the disease, the disease comes back.

The Systemic Problem With AI Tooling

Langflow isn't uniquely reckless here. Code evaluation is a feature, not a bug, in most AI workflow platforms. The whole point of these tools is to let users define custom logic — connect to APIs, transform data, run code against results. That means the platform needs to run user-supplied code at some level.

The question is how you contain it. And right now, most AI workflow tools aren't doing a great job:

• n8n had its own sandbox escape vulnerabilities (CVE-2026-27577, CVE-2026-27493) disclosed earlier this year
• LangChain, the library Langflow is built on, has had code evaluation concerns raised repeatedly
• AutoGen, MetaGPT, and other agent frameworks all run code as a core part of their operation

These tools are designed for developer productivity, not security. They ship with permissive defaults because friction kills adoption. Langflow's AUTO_LOGIN=true default is a perfect example — it makes the getting-started experience seamless, but it means every fresh installation is one HTTP request away from handing out superuser tokens.

The AI tooling ecosystem is roughly where web frameworks were in the mid-2000s: powerful, popular, and full of code injection vulnerabilities that nobody wants to slow down to fix.

What You Should Do Right Now

If You Run Langflow

Update to version 1.9.0 immediately. Not 1.8.2 — that version is still vulnerable despite what some sources report. If 1.9.0 isn't available in your deployment method yet, use langflow-nightly 1.9.0.dev18 as an interim measure.

Rotate every secret in the environment. If your Langflow instance was accessible from the internet at any point since March 17, assume your API keys, cloud credentials, and database connection strings have been compromised. Rotate all of them. Yes, all of them.

Check for signs of compromise. Look at your Langflow access logs for requests to /api/v1/build_public_tmp/ with unexpected data parameters. Check for outbound network connections to unfamiliar hosts. Review whether any new users or flows were created that you don't recognize.

Disable public flow building if you don't need it. If users don't need to run flows without authentication, turn the feature off entirely.

If You Run Any AI Workflow Tool

Don't expose it to the internet without authentication. This sounds obvious, but Censys found over a thousand Langflow instances directly accessible. Put these tools behind a VPN, a zero-trust gateway, or at minimum a reverse proxy with authentication. They are not designed to be internet-facing services.

Set AUTO_LOGIN=false on Langflow, and check the equivalent setting on whatever other tools you run. Default configurations optimize for ease of setup, not security.

Treat AI tools like you'd treat a database. You wouldn't expose PostgreSQL directly to the internet. You wouldn't run it with default credentials. Apply the same thinking to Langflow, n8n, and any other tool that evaluates code as part of its core functionality.

Monitor outbound network traffic. An AI workflow tool that suddenly starts making HTTP requests to unfamiliar servers is a red flag. If your monitoring can detect it, you can catch a compromise before it exfiltrates everything.

Audit what credentials your AI tools can access. Do they have your AWS root keys? Your production database password? API keys with unlimited spend? Scope the credentials down to what the tool actually needs. A workflow that summarizes documents doesn't need your cloud admin credentials.

The Window Is Shrinking

The twenty-hour exploitation timeline is the real takeaway here. Not that Langflow had a vulnerability — every complex software does. Not that the patch was botched — that happens. The speed at which attackers weaponized a text advisory into working exploitation against real targets is what should keep you up at night.

If you're running internet-facing AI tooling and your patch cycle is measured in weeks, you're operating on borrowed time. The attackers who hit Langflow didn't wait for a Metasploit module or a script-kiddie tool. They read the advisory, understood the code, and started stealing credentials the same day.

CISA's deadline for federal agencies to patch is April 8. Don't wait until then.

Sources: Sysdig TRT, JFrog Security Research, BleepingComputer, CISA KEV Catalog, The Hacker News