Langflow is an open-source platform for visually building AI agent workflows. It lets users compose chains of language model calls, tools, and integrations through a drag-and-drop interface, connecting components like LLM providers, databases, API services, and custom Python code into automated pipelines. With over 140,000 GitHub stars, it is one of the most popular tools in the AI agent space. Organizations use it to prototype and deploy AI-powered workflows that often have access to sensitive systems: API keys for cloud services, database credentials, internal tools, and customer data.

In 2025, two separate critical vulnerabilities revealed that the platform's security foundations were not built to match the access it routinely held.

CVE-2025-3248: exec() without authentication

The first vulnerability, CVE-2025-3248, is about as direct a remote code execution flaw as they come. Langflow included an API endpoint at /api/v1/validate/code that was designed to validate Python code snippets submitted by users building custom components. The validation process parsed the submitted code into a Python Abstract Syntax Tree (AST), extracted function definitions, and then executed them using Python's built-in exec() function to verify they worked.

The endpoint had no authentication requirement. Any network request to the endpoint would be processed. And exec() is exactly what it sounds like: it runs arbitrary Python code on the server.

The exploitation mechanism was straightforward. Python evaluates certain code at function definition time, not at function call time. Decorators are evaluated when they are applied to a function, and default argument values are evaluated when the function object is created. An attacker could submit code where the malicious payload was embedded in a decorator or a default argument, and it would execute during the validation step itself - before any check could determine whether the code was safe.

A payload as simple as a decorator calling exec() with an os.system() command inside it would grant the attacker arbitrary command execution on the server. The server would return a normal-looking validation response while the embedded code had already run. From there, an attacker could read files, write web shells, exfiltrate environment variables containing API keys and database passwords, or pivot to other systems accessible from the Langflow server.

Horizon3.ai security researchers reported the vulnerability to Langflow on February 22, 2025, through a GitHub security issue. The CVE was assigned on April 7, 2025, and Horizon3.ai published detailed exploit analysis on April 9 under the title "Unsafe at Any Speed." Langflow released version 1.3.0 to address the issue by requiring authentication on the code validation endpoint.

On May 5, 2025, CISA (the Cybersecurity and Infrastructure Security Agency) added CVE-2025-3248 to its Known Exploited Vulnerabilities catalog, indicating evidence of active exploitation in the wild. Federal agencies were given a deadline of May 26, 2025 to patch or discontinue use of vulnerable Langflow versions. Zscaler's ThreatLabz also published analysis of the vulnerability, documenting the attack chain and recommending that organizations place Langflow behind zero-trust network access controls.

The CVSS score was 9.8 out of 10 - the highest tier of severity - reflecting the combination of factors: no authentication required, network-accessible, no user interaction needed, and full compromise of confidentiality, integrity, and availability.

CVE-2025-34291: account takeover via malicious webpage

The second vulnerability, discovered by Obsidian Security, was a different kind of problem. CVE-2025-34291 (CVSS 9.4 under version 4.0 scoring) was not a single flaw but a chain of three weaknesses that, combined, allowed an attacker to take over a Langflow user's account and achieve remote code execution just by getting them to visit a malicious web page.

The chain worked like this. First, Langflow's default CORS (Cross-Origin Resource Sharing) configuration was overly permissive, allowing requests from any origin. Second, the token refresh endpoint lacked CSRF (Cross-Site Request Forgery) protection - the authentication cookie was set with SameSite=None, meaning the browser would include it in cross-origin requests. Third, the attacker could use the hijacked authentication token to call the same /api/v1/validate/code endpoint exploited in CVE-2025-3248, achieving remote code execution.

In practice, this meant an attacker could set up a web page that, when visited by a logged-in Langflow user, would silently make authenticated requests to their Langflow instance. The attacker's page would first trigger a token refresh to capture a valid access token, then use that token to submit arbitrary Python code for execution on the server. The victim did not need to click anything, enter credentials, or interact with the malicious page in any way beyond loading it.

The impact went beyond compromising the Langflow instance itself. Langflow workspaces typically contain stored API keys, access tokens, and credentials for every service the AI workflows connect to - OpenAI, Anthropic, AWS, databases, internal APIs. A successful exploit exposed all of those credentials. CrowdSec confirmed that CVE-2025-34291 was being actively exploited in the wild, though the nature of the attack (cross-site requests) made it difficult to fully quantify the scope of exploitation.

CVE-2025-34291 affected versions up to and including 1.6.9. Langflow 1.7 fixed the default CORS configuration to prevent the attack.

The compounding problem

What makes these vulnerabilities notable beyond their individual severity is how they interacted. CVE-2025-3248 was patched in version 1.3.0 by adding authentication to the vulnerable endpoint. But CVE-2025-34291 made it possible to bypass that authentication by stealing a valid token. The fix for the first vulnerability was undermined by the second. An organization that diligently upgraded to 1.3.0 to address the unauthenticated RCE was still vulnerable to authenticated RCE via the CSRF chain until they upgraded again to 1.7.

This pattern - patching a symptom while leaving the underlying architectural weakness intact - is common in rapidly growing open-source projects. Langflow's code validation endpoint existed because the platform lets users write custom Python components. The decision to validate those components by executing them was a design choice that prioritized functionality over security. Adding authentication was a mitigation, not a fix for the fundamental problem of running untrusted code with exec().

Scale and context

Langflow's popularity means the blast radius of these vulnerabilities was substantial. The platform is used by organizations building internal AI tools, customer-facing chatbots, document processing pipelines, and automated decision systems. Each of these deployments holds credentials for the services it orchestrates. A compromised Langflow instance does not just give an attacker access to the AI platform - it gives them the keys to every system the AI platform connects to.

The Horizon3.ai researchers titled their disclosure "Unsafe at Any Speed," referencing Ralph Nader's 1965 book about automotive safety failures. The implication was deliberate: Langflow's architecture had a running-arbitrary-code endpoint exposed to the network, and the fix was an afterthought applied only after external researchers found it. The CISA KEV listing confirmed that attackers found it too.

For organizations running AI agent platforms, the Langflow vulnerabilities illustrate a specific risk profile. AI workflow tools are designed to connect to many systems & hold credentials for all of them. They run user-defined logic that may include arbitrary code. They are often deployed by data science or ML teams who may not follow the same security practices as traditional application development teams. And because they are relatively new tools, their security posture has not been battle-tested the way established web frameworks have.

Both vulnerabilities were patched. But the months between disclosure and fix, combined with active exploitation in the wild, meant that an unknown number of Langflow instances were compromised before the patches could be applied. The stored credentials exposed during that window may have given attackers persistent access to connected systems long after the Langflow vulnerabilities themselves were closed.