LangFlow Vulnerability Myths: What Developers Get Wrong

The Attack Is Already Inside

Let’s cut through the noise: right now, roughly 7,000 Langflow servers are exposed on the public internet, and attackers are actively exploiting them. This isn’t a theoretical scenario or a proof-of-concept running in some research lab. VulnCheck’s sensors caught the first in-the-wild exploitation on June 9, 2026. The attacks started less than two months after the patch dropped in April.

Here is the uncomfortable truth: three of the most deployed AI agent frameworks—LangGraph, Langflow, and LangChain-core—each turned ordinary bug classes into full remote code execution paths. That is the same bug, wearing three different framework logos. And if you are building AI agents in production, you are probably using at least one of them without knowing the attack surface you just inherited.

Myth 1: AI Agent Frameworks Are Secure by Default

You might think the framework developers shipped these tools with security baked in. That is the myth. The reality is uglier.

Langflow ships with auto-login enabled in its default configuration. No password. No API key. Just open the door and wait. That is not a misconfiguration on your end—it is how the framework arrives out of the box.

LangChain-core fares no better. Its legacy prompt-loading API, the load_prompt() function, reads file paths directly from config dictionaries with zero validation. No check for traversal sequences. No check for absolute paths. Hand it a path, and it reads whatever the process can reach—including your .env file holding OPENAI_API_KEY and ANTHROPIC_API_KEY.

Merritt Baer, CSO at Enkrypt AI and former deputy CISO at AWS, put it bluntly: “MCP is shipping with the same mistake we’ve seen in every major protocol rollout: insecure defaults.” She is right. The convenient default is the vulnerability. When your agent connects to a database, a CRM, or an internal API, you are not just trusting your own security—you are inheriting the hygiene of every tool, every credential, and every developer in that chain. That is supply chain risk in real time.

Myth 2: These Are New, AI-Specific Vulnerabilities

If you think SQL injection is a problem unique to AI models, think again. These are not exotic, AI-specific flaws. They are decades-old bugs living inside new infrastructure.

CVE-2025-67644, the SQL injection in LangGraph’s SQLite checkpointer, builds a WHERE clause by dropping user-controlled filter keys straight into the query with no parameterization and no escaping. That is textbook 1990s coding. The only thing new here is the target— LangGraph’s checkpoint storage layer.

Path traversal? CVE-2026-5027 in Langflow’s file upload endpoint takes a filename from form data and writes it to disk unsanitized. Attackers packed traversal sequences into the filename and dropped files anywhere they wanted—including cron jobs in /etc/cron.d/. That gets them a shell on the next cron run.

CVE-2026-34070 in LangChain-core’s prompt loader? Same bug, different entry point. Unsafe deserialization in CVE-2025-68664 lets attackers resolve environment secrets through a crafted object. None of this is frontier-model stuff. It is plumbing—sitting in the layer where AI meets the enterprise.

Myth 3: Your WAF or Scanner Will Catch This

You might feel safe behind your WAF or endpoint detection tool. That confidence is misplaced.

The exploit lives inside the framework your code imports. It runs three layers down from your application logic. Your WAF watches HTTP traffic at the edge. It never sees the msgpack checkpoint decoder rebuilding Python objects from stored data. Your EDR watches the agent server make process calls—it makes the same calls a thousand times a day, so it waves the malicious activity right through.

Both tools are doing their jobs. Nobody scoped the imported framework itself as the thing that could turn on you. That is the gap. As Baer told VentureBeat: “CISOs will experience MCP insecurity not in the abstract, but when an employee pastes sensitive data into a tool, or when an attacker finds an unauthenticated MCP server in your cloud. It won’t feel like ‘AI risk.’ It will feel like your traditional security program failing.”

The scanner cannot see it because the vulnerability does not announce itself as an AI problem. It looks like ordinary application behavior—until it is not.

Myth 4: Managed Services Mean You’re Protected

If you are running LangGraph on LangSmith’s managed PostgreSQL platform, you might think you dodged the bullet. The SQLite SQL injection does not apply to you. But here is the catch—one patch does not clear the chain.

Remember CVE-2026-28277, the msgpack checkpoint decoder? It rebuilds Python objects from stored data and lets an attacker import a module and call a named function with supplied arguments. The SQL injection gets an attacker write access to the checkpoint store. Then the msgpack decoder does the rest—running os.system under the identity of the agent server.

The PostgreSQL checkpointer removes one link in the attack chain. It does not touch the decoder bug. You patched CVE-2025-67644? Great. But CVE-2026-28277 is still sitting there, waiting for the right conditions. One vulnerability does not equal security. These flaws chain together, and you need to clear every link in the chain.

The Real Problem: Framework-as-Boundary

Here is where the mental model breaks down. Neither your edge tools nor your endpoint tools treat the imported framework as a trust boundary worth guarding. That is the design blind spot.

Your WAF watches traffic. Your endpoint tools watch processes. Neither was built to treat an imported framework as a boundary worth guarding, and that blind spot is exactly where all three chains live—widening every week as these frameworks ship to production.

These frameworks became production infrastructure faster than anyone secured them. They store agent state, take file uploads, load prompt configs, and hold the credentials to databases, CRMs, and internal APIs. They are the plumbing connecting your AI agent to every system in your enterprise. And nobody drew a line around them.

The lesson for security teams is brutal but clear: start the patch clock at disclosure, not at a federal catalog entry. The Langflow patch shipped April 15. Attacks started in June. Every instance left unpatched between those two dates sat in the open for almost two months. That is the window attackers lived inside.

If you are building with LangGraph, Langflow, or LangChain-core today, the question is not whether you are vulnerable. It is whether you have already imported the vulnerability and forgotten about it. Audit your dependencies. Patch everything. And treat your framework imports like the trust boundary they should have been from day one.