CVE-2025-34291: Critical Account Takeover and RCE Vulnerability in the Langflow AI Agent & Workflow Platform

Executive Summary

Security researchers at Obsidian Security have uncovered a critical vulnerability chain in Langflow, a popular open-source AI agent and workflow platform (over 140K GitHub stars).

This flaw, tracked as CVE-2025-34291 (CVSS v4.0: 9.4), enables an attacker to achieve complete account takeover and Remote Code Execution (RCE) simply by having a user visit a malicious webpage.

The vulnerability chain exploits three combined weaknesses:

1. Overly Permissive CORS: Langflow allows cross-origin requests with credentials from any source.
2. Lack of CSRF Protection: The token refresh endpoint lacks CSRF defenses (SameSite=None), allowing attackers to send cross-site authenticated request
3. Code Validation Endpoint: An endpoint that allows code execution by design.

The impact is severe: successful exploitation not only compromises the Langflow instance but also exposes all sensitive access tokens and API keys stored within the workspace. This can trigger a cascading compromise across all integrated downstream services in cloud and SaaS environments.

‍

‍

Background

A token opens doors — to you, or to whoever holds it.

The recent Salesloft-Drift incident showed the damage possible. Threat actor UNC6395 leveraged compromised OAuth tokens to conduct mass data exfiltration from approximately 700 Salesforce organizations, including major tech companies like Cloudflare, Zscaler, and Palo Alto Networks.

AI agent and workflow platforms have become integration hubs for external services and data systems. Every integration adds more credentials, concentrating sensitive access in one place. That concentration creates a high-value target: a single breach can hand attackers a “master key” to all connected systems.

For shared platforms, one breach can hit many organizations; for self-hosted ones, one breach can expose many services within a single organization. Given these risks, we initiated a security assessment of prominent open-source AI agent and workflow platforms to identify potential vulnerabilities that could lead to total compromise of the underlying systems.

We selected Langflow as our primary research target - an open-source, low-code visual framework for building AI workflows, RAG applications, and multi-agent systems with over 140,000 GitHub stars. Built on Python and FastAPI, Langflow provides an intuitive drag-and-drop interface that enables developers to create complex AI applications without extensive coding.

‍

‍

Notably, Langflow was acquired by DataStax in April 2024, and DataStax is currently being acquired by IBM (announced February 2025), making Langflow part of IBM’s expanding watsonx AI portfolio.

‍

Deep Dive into Langflow

CVE-2025-3248: A Two-Year Journey

Langflow is young and shipping fast - exactly the kind of project that rewards a deep security dive. A good entry point is its vulnerability history. Just a few months ago, CVE-2025-3248 surfaced: a critical, unauthenticated RCE affecting versions prior to 1.3.0.

What makes it compelling isn’t only the severity, but the story: a nearly two-year arc from initial discovery to final fix, an unusually long window that exposes architectural trade-offs and how Langflow’s security posture has evolved.

Timeline of Discovery and Remediation:

• July 27, 2023: GitHub user @Lyutoon opens Issue #696, identifying that an unauthenticated code-validation endpoint can be exploited for RCE through a function definition’s default parameter.
• November 10, 2024: Github user @nimasteryang submits a pull request #4488 attempting to address the vulnerability, but the fix was abandoned because it would break existing features.
• February 22, 2025: Security researchers at Horizon3.ai report the vulnerability to Langflow through GitHub security issue, identifying a second, distinct RCE vector that abuses a function decorator to trigger RCE during code validation.
• March 3, 2025: Langflow team implements authentication requirements on the vulnerable endpoint #6911, officially patching CVE-2025-3248

This near-two-year timeline underscores a familiar trade-off: especially in AI, teams rush to build and win adoption, and security trails behind.

‍

The Vulnerability: A Quick Refresher

Let’s briefly revisit how this vulnerability worked.

The core issue stemmed from Langflow’s /api/v1/validate/code endpoint, which was designed to validate Python code snippets for custom components. However, before version 1.3.0, this endpoint was accessible without any authentication:

src/backend/base/langflow/api/v1/validate.py

‍

The validate_code() function would parse the provided code, check if it contains function definitions, and then execute those functions to validate them:

src/backend/base/langflow/utils/validate.py

The code assumes function definitions are safe to execute. They’re not. When exec() evaluates a function definition, it immediately executes expressions in default arguments and decorators.

‍

With no sandboxing in place, any unauthenticated user could fully compromise the system with a single POST to /api/v1/validate/code.

The vulnerability was actively exploited in the wild, with threat actors deploying the Flodric botnet through compromised Langflow instances, as documented by Trend Micro’s research.

‍

From Open to Protected

In response to CVE-2025-3248, authentication was added to the /api/v1/validate/code endpoint. When a request hits the endpoint, FastAPI’s dependency injection automatically triggers the authentication flow.‍

Endpoint declares authentication requirement

‍

Verify user account is active

‍

Perform actual authentication check

The get_current_user() function checks two authentication sources in priority order:

First: JWT token from Authorization: Bearer <token> header

‍Second: API key from x-api-key header or query parameter

Post-patch, the code validation endpoint is no longer open by default. Hitting it now requires either a valid JWT token or a valid API key.

‍

From Protected to Compromised: CVE-2025-34291

Authentication looks solid on paper. So the practical question becomes: can we obtain or leverage valid credentials? Three angles:

1) API key

Not promising. API keys aren’t provisioned by default, users must explicitly create them in settings. The attack surface is limited.

2) CSRF and CORS?

This is the interesting path. Without proper CSRF protections, an attacker can issue cross-site write requests on behalf of the user. And with a misconfigured CORS policy, the attacker can also perform cross-origin read, gaining access to the sensitive responses returned by those authenticated requests.

3) XSS to steal JWT token

The backend generates and signs a JWT (HS256) during login, then sets it in the access_token_lf cookie (SameSite=Lax) as part of the HTTP response. It also includes the same token in the response body.

The frontend then reads this cookie and includes the token in all API requests via an Axios interceptor using the standard Authorization: Bearer <token> header.

In other words, the JWT token is the same value stored in the access_token_lf cookie. Because the cookie is not HttpOnly, it could be read by client-side JavaScript — though this would require a separate XSS vulnerability in Langflow.

Fortunately, approach 2 worked: we identified two misconfigurations that, together, completely bypass authentication.

‍

CORS Misconfiguration

By default, Langflow uses FastAPI’s CORSMiddleware with permissive settings, allowing requests from any origin. Additionally, allow_credentials is set to True, which allows attackers to make cross-origin requests with credentials.

langflow/main.py#L292-L300

However, two issues prevent further exploitation:

• Issue 1: The authentication cookie access_token_lf is set with SameSite=Lax, which excludes it from most cross-site contexts (XHR/fetch/POST) except for user-initiated top-level GET navigations.
• Issue 2: In Langflow versions 1.5 and later, most API endpoints require additional authentication — either by providing a Langflow API key or by including an JWT token in the Authorization header, which is not automatically included in cross-origin requests.

So we shouldn’t be able to send authenticated cross-origin requests. This CORS setting seemed harmless - until one overlooked detail reignited the exploit chain.

‍

refresh_token_lf Cookie Misconfiguration

The refresh_token_lf cookie is configured with SameSite=None; Secure, making it accessible in cross-site contexts over HTTPS. It also remains valid for up to one week, giving attackers a longer window to exploit it.

The /api/v1/refresh endpoint relies on this cookie as its only authentication mechanism and implements no additional CSRF protections.

As a result, a cross-origin request to /api/v1/refresh from an attacker-controlled domain can successfully obtain a fresh pair of tokens: both an access_token and a new refresh_token, thereby enabling full session hijack.

‍

With a valid access token in hand, an attacker can simply issue another cross-origin request to exploit CVE-2025-3248 and achieve remote code execution.

‍

Steps to Reproduce

Environment Setup

1. Set up Langflow locally using Docker Compose with HTTPS enabled:

‍
2. Access Langflow: Open https://<server-addr>:443 in your browser, replacing <server-addr> with the IP/Host of the server where Langflow is deployed.

3. Login: Use the default credentials admin:admin to start a new user session.

Proof of Concept

1. Open the PoC page: Navigate to https://www.pocs.app/langflow-cors-vul-poc.html‍

2. Configure target: Change the target base URL, then click Launch Exploit.

3. Watch the magic happen: Within a few seconds, the following will occur:

• The browser sends a cross-origin POST /api/v1/refresh request with victim’s cookie
• The PoC extracts the access_token and refresh_token‍
• Then it triggers an RCE via the /api/v1/validate/code endpoint

4. Results: The environment variables or other sensitive data will be shown in the PoC terminal panel.

‍

‍

Impact

Langflow uses global variables to store and reuse credentials and other generic values across flows. These variables are persisted in its internal database, and their values are encrypted using a secret key.

Once the system is compromised, those values become trivial for an attacker to decrypt.

Full session hijack and RCE - Complete system compromise through a single malicious webpage visit. Because the request originates from the victim’s browser via CORS, even non-public facing on-prem instances are exploitable.

The RCE vulnerability is particularly dangerous in Langflow’s context as an AI agent and workflow platform. Attacker can access the project’s flows as well as the privileged credentials stored within the workspace — including API keys, database passwords, and service tokens used to connect SaaS, cloud and other environments. This drastically enlarges the blast radius beyond just the Langflow instance itself, making Langflow alike Agent builder platform a single point of failure.

‍

Security Lesson

Langflow has been slow to ship a complete fix, seemingly out of concern that tightening cookie/CORS settings might break front-end/back-end split deployments.

From a security perspective, the question is: how should the refresh endpoint be protected?

1. If authentication is cookie-based, proper CSRF protection becomes mandatory. For same-site deployments (e.g., https://app.example.com → https://api.example.com, which are cross-origin but still same-site), the refresh cookie can safely use SameSite=Lax or Strict (with Secure and ideally HttpOnly). If the frontend and backend are not same-site and SameSite=None is required for functionality, then an explicit CSRF-token mechanism must be added.

2. Preferably, refresh tokens are best sent via HTTP headers rather than cookies. Using Authorization: Bearer <refresh_token> removes CSRF from the threat model entirely, avoids browser-managed credential attachment. It also simplifies CORS hardening.

Last but not least, this vulnerability did not stem from a single critical flaw but rather from the convergence of several individually minor configuration choices that, when combined, created a severe attack vector. This incident highlights an essential lesson: in complex systems, even seemingly innocuous design decisions can interact in unexpected ways. It underscores the importance of holistic security reviews and secure-by-default configurations - especially as AI platforms become deeply embedded in enterprise workflows and handle increasingly sensitive data.

‍

Mitigations & Fixes

Upon responsible disclosure, the Langflow team acknowledged the issue and initiated a series of fixes. According to the Langflow development notes:

• Version 1.6.0 introduces new environment variables that allow users to fully customize Langflow’s CORS configuration.
• In the upcoming version 1.7, both CORS and the refresh_token_lf cookie will adopt more secure defaults:
  • CORS will allow credentialed requests only from explicitly specified origins
  • refresh_token_lf cookie will default to SameSite=Lax to reduce cross-site exposure.

As of this publication, the latest official release is 1.6.9, and 1-click RCE remains fully exploitable under default settings.

Organizations can manually harden their deployment by following the official CORS guidance. As an alternative, the fix from PR #10139 can be applied to update REFRESH_SAME_SITE to Strict or Lax at the source level if the frontend and backend are same-site.

Additionally, the Langflow team is developing a sandbox for the code validation endpoint #10696. Hopefully, this will fully resolve the underlying RCE risk.

‍

Vulnerability Disclosure Timeline

• July 29, 2025 — Submitted the vulnerability via GitHub security issue; also reported it on HackerOne to DataStax as a fallback.
• July 29, 2025 — Langflow opened PR #9240 (“Improve cookie security”). This front-end change had no effect on httpOnly cookies (must be configured on the backend), so it did not mitigate the issue.
• July 31, 2025 — Report triaged on HackerOne.
• August 5, 2025 — Requested an update on GitHub security issue.
• September 7, 2025 — Requested an update on GitHub security issue.
• September 11, 2025 — Langflow opened PR #9441 (“Add env vars to allow user control”) and added a warning: “in v1.7, credentials will be automatically disabled when using wildcard origins”.
• September 25, 2025 — Langflow 1.6.0 released: introduces environment variables to customize CORS allowed origins. However, the default configuration remains vulnerable.
• September 26, 2025 — Requested an update on HackerOne.
• October 3, 2025 — DataStax replied: “this is with the team.”
• October 22, 2025 — Still no updates on GitHub security issue; asked VulnCheck to assign a CVE.
• October 23, 2025 — CVE-2025-34291 assigned. Shout-out to the VulnCheck team for the fast CVE help.
• November 4, 2025 — Four months had elapsed, and since users could manually mitigate by adjusting their CORS configuration, we proceeded with publishing the research.

‍