CVE-2025-34291: Langflow AI Intelligence Body and Workflow Platform Account Takeover and Remote Code Execution Vulnerability

1. Background

A token can open doors for you or whoever holds it.

recentSalesloft-DriftThe incident exposed the damage such attacks can cause. The attacker, UNC6395, used stolen OAuth tokens to steal data on a massive scale from approximately 700 Salesforce organizations, including large tech companies such as Cloudflare, Zscaler and Palo Alto Networks.

AI代理和工作流平台已成为外部服务和数据系统的集成中心。每次集成都会增加更多凭证，将敏感访问权限集中在一处。这种集中化使得攻击者成为高价值目标：一次安全漏洞就可能让攻击者获得所有连接系统的“主密钥”。

For shared platforms, a single security breach could affect multiple organizations; for self-hosted platforms, a single security breach could expose multiple services within a single organization. In light of these risks, we conducted security assessments of a number of well-known open source AI agents and workflow platforms to identify potential vulnerabilities that could lead to a complete breakdown of the underlying system.

We chose Langflow as our primary research subject - an open source, low-code visualization framework for building AI workflows, RAG applications, and multi-intelligence systems with over 140,000 stars on GitHub.Built on Python and FastAPI, Langflow Langflow is built on Python and FastAPI, and provides an intuitive drag-and-drop interface that enables developers to create complex AI applications without writing tons of code.

‍

‍

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

2、Langflow depth analysis and application

2.1, CVE-2025-3248: two years of history

Langflow is a young and rapidly iterating program - exactly the type of program that deserves a deeper look into its security. A good entry point is its vulnerability history. Just a few months ago, the CVE-2025-3248 vulnerability surfaced: a serious and unauthenticated remote code execution vulnerability affecting versions prior to 1.3.0.

What's really striking is not only the severity of the problem, but also the story behind it: nearly two years from initial discovery to final fix, an unusually long period of time that exposes the architectural tradeoffs and how Langflow's security posture has evolved.

Discovery and remediation schedule:

• July 27, 2023: GitHub user @Lyutoon submitted Issue #696It is noted that unauthenticated code validation endpoints can be utilized for Remote Code Execution (RCE) via default parameters in function definitions.
• November 10, 2024: Github user @nimasteryang submitted a pull request #4488, attempted to address the vulnerability, but the fix was abandoned because it would have broken existing functionality.
• February 22, 2025 Horizon3.ai's security researchers reported a vulnerability in Langflow via GitHub Security Issues, discovering a second, different RCE vector that utilizes a function decorator to trigger an RCE during code validation.
• March 3, 2025: Langflow team on vulnerable endpoints#6911Implement authentication requirements on to formally fix the CVE-2025-3248 vulnerability.

The timeline of the last two years highlights a familiar trade-off: especially in AI, teams are scrambling to build and win adoption while safety is left behind.

2.2. Vulnerabilities: a quick review

Let's briefly review how this vulnerability works.

The core problem stems from Langflow's/api/v1/validate/codeAn interface designed to authenticate Python code snippets for custom components. However, prior to version 1.3.0, this interface could be accessed without any authentication:

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

‍

ought tovalidate_code()The function parses the supplied code, checks to see if it contains function definitions, and then executes those functions to verify them:

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

This code assumes that function definitions are safe to execute. This is not the case. When the `exec()` function executes a function definition, it immediately executes the default arguments and the expression in the decorator.

‍

Without the sandboxing mechanism, any unauthenticated user could completely compromise the system by sending a POST request to the server/api/v1/validate/code.

This vulnerability has been actively exploited by threat actors deploying Flodric botnets through compromised Langflow instances.Trend Micro studyThis was recorded.

3. From openness to closure

In response to CVE-2025-3248, we added authentication functionality to the /api/v1/validate/code endpoint. When a request reaches this endpoint, FastAPI's dependency injection mechanism automatically triggers the authentication process.

3.1. Endpoint statement authentication requirements

‍

3.2. Verify that user accounts are active

‍

3.3. Perform physical authentication checks

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

in the first place: JWT token from Authorization: Bearer header

second type: API key from x-api-key header or query parameter

The code validation endpoint is no longer open by default after the patch was released. Access to this endpoint now requires a valid JWT token or a valid API key.‍

4. From protected to leaked:CVE-2025-34291

Authentication looks perfect in theory. Therefore, the practical question becomes: can we obtain or utilize valid credentials? The following three areas are of interest:

1) API key

The outlook is worrisome. the API key is not auto-configured by default and must be explicitly created by the user in the settings. Limited attack surface.

2) CSRF and CORS?

This is an interesting path. Without proper CSRF protection, an attacker cancross-site writeMake a request as a user. If the CORS policy is misconfigured, there are other actions that an attacker can performcross-origin readto obtain the sensitive response returned by the authenticated request.

3) Stealing JWT tokens with XSS

The backend generates and signs the JWT (HS256) during login and then sets it as part of the HTTP response to theaccess_token_lfcookieSameSite=Lax. The same token is included in the body of the response.

The front-end then reads this cookie and uses the standardAuthorization: Bearerheader includes this token in all API requests.

In other words, the value of the JWT token is the same as the value of theaccess_token_lfThe value stored in the cookie is the same. Since cookies are not encryptedHttpOnlyThe first is that it can be read by client-side JavaScript - but that would require a separate XSS vulnerability in Langflow.

Fortunately, method 2 worked: we found two configuration errors that together completely bypassed authentication.

4.1. CORS misconfiguration

By default, Langflow uses FastAPI's CORSMiddleware with loose settings to allow requests from any source. In addition, theallow_credentialsThis setting is also set to True to allow an attacker to initiate cross-domain requests using credentials.

langflow/main.py#L292-L300

However, there are two issues that prevent further exploitation:

• Issue 1: Authentication cookieaccess_token_lfconfiguredSameSite=Lax, which would exclude it from most cross-site contexts (XHR/fetch/POST), except for top-level user-initiated GET navigation.
• Issue 2: In Langflow 1.5 and later, most API endpoints require additional authentication - either by providing a Langflow API key or by including a JWT token in the Authorization header, which is not automatically included in cross-domain requests.

Therefore, we should not be able to send authenticated cross-domain requests. This CORS setup seems harmless enough - until an overlooked detail reignites the attack chain.

4.2. refresh_token_lf cookie configuration error

ought torefresh_token_lfCookies are configuredSameSite=None; Securewhich makes it accessible in a cross-site context via HTTPS. In addition, it is valid for up to a week, which gives attackers a longer window to attack.

ought to/api/v1/refreshThe endpoint relies solely on this cookie as its authentication mechanism and does not implement any additional CSRF protection.

As a result, a cross-domain request from an attacker-controlled domain/api/v1/refreshA new pair of tokens can be successfully acquired: a tokenaccess_tokenand a new tokenrefresh_tokenand thus achieve complete session hijacking.

‍

An attacker in possession of a valid access token could simply issue another cross-domain request to exploit the CVE-2025-3248 vulnerability and enable remote code execution.

‍

5. Reproduction steps

5.1. Environmental settings

1. Configure Langflow locally with Docker Compose and enable HTTPS.:

‍
2. Visit to Langflow:https://:443Open it in your browser and replace<server-addr>is the IP/hostname of the server where Langflow is deployed.

3. Login: Use the defaultadmin:adminCredentials to start a new user session.

5.2 Proof of concept

1. Open the PoC page: Navigationhttps://www.pocs.app/langflow-cors-vul-poc.htmluntil

2. Configuration objectives: Change the target base URL and clickLaunch Exploit.

3. Witnessing miracles: Within a few seconds, the following will happen:

• POST /api/v1/refreshThe browser sends a cross-domain request containing the victim cookie.
• PoC extracted andaccess_tokenrefresh_token
• It then passes the/api/v1/validate/codeEndpoint triggers Remote Code Execution (RCE).

4. Results: Environment variables or other sensitive data will be displayed on the PoC terminal panel.

6. Impact of vulnerabilities

Langflow uses global variables to store and reuse credentials and other common values across processes. These variables are stored persistently in its internal database and their values are encrypted using keys.

Once the system is compromised, it is easy for an attacker to decrypt these values.

Full Session Hijacking and Remote Code Execution - Full control of the system can be achieved with a single malicious web visit. Since requests are initiated from the victim's browser via CORS, even non-public locally deployed instances can be exploited.

Remote Code Execution (RCE) vulnerabilities are particularly dangerous in the context of Langflow's role as an AI agent and workflow platform. Attackers can access project processes and privileged credentials stored in the workspace, including API keys, database passwords, and service tokens used to connect to SaaS, cloud, and other environments. This greatly expands the scope of the attack beyond the Langflow instance itself, making agent build platforms such as Langflow a single point of failure.

6.1 Security recommendations

Langflow's delay in releasing a full fix seems to be due to concerns that tightening cookie/CORS settings might break front-end/back-end separation deployments.

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

1. If authentication is based on cookies, appropriate CSRF protection must be in place. For same-site deployments (e.g., https://app.example.com → https://api.example.com, which is cross-domain but still belongs to the same site), refreshing cookies can be done securely using SameSite=Lax or Strict (preferably with both Secure and HttpOnly enabled). If the front-end and back-end are not on the same site If the front-end and back-end are not on the same site, and some functionality requires SameSite=None, an explicit CSRF tokenization mechanism must be added.

2. Refresh tokens should preferably be sent via HTTP headers instead of cookies. The use of `Authorization: Bearer ` completely eliminates the CSRF threat model, avoids browser-managed credential attachments and simplifies CORS hardening.

Last but not least, the vulnerability did not stem from a single critical flaw, but rather was the result of a combination of seemingly innocuous configuration choices that combined to form a serious avenue of attack. This incident highlights an important lesson: In complex systems, even seemingly innocuous design decisions can interact in unexpected ways. It emphasizes the importance of comprehensive security reviews and default security configurations - especially as AI platforms become increasingly embedded in enterprise workflows and handle increasingly sensitive data.

6.2 Mitigation Measures Program

After responsibly disclosing the issue, the Langflow team acknowledged the issue and initiated a series of fixes. According to the Langflow development logs:

• Version 1.6.0Introduced new environment variables that allow users to fully customize Langflow's CORS configuration.
• In the upcoming 1.7 releaseThe following are some examples of the types of services offered by CORS andrefresh_token_lfThe cookies will all be set to more secure default settings:
  • CORS only allows authenticated requests from explicitly specified sources.
  • refresh_token_lfThe cookie will be set by default toSameSite=LaxReduce cross-site exposure.

As of this writing, the latest official version is 1.6.9, and 1-click Remote Code Execution (1-click RCE) is still fully utilized with the default settings.

Organizations can followOfficial CORS GuideManually enhance its deployment. Alternatively, if the front-end and back-end are located at the same site, PR can be applied #10139The restoration program in theREFRESH_SAME_SITEUpdates are made at the source code level.StrictLax

In addition, the Langflow team is working on a code validation endpoint for the#10696Development Sandbox. Hopefully this will completely solve the potential remote code execution risk.

6.3. Vulnerability disclosure schedule

• July 29, 2025- The vulnerability was submitted via GitHub Security Issues; it was also reported to DataStax on HackerOne as a backup.
• July 29, 2025--Langflow submitted PR #9240("Improve cookie security"). This front-end change has no effect on the httpOnly cookie (which must be configured on the back-end), so it does not alleviate the problem.
• July 31, 2025- Reports on HackerOne are categorized.
• August 5, 2025--Request for an update on GitHub security issues.
• September 7, 2025--Request for an update on GitHub security issues.
• September 11, 2025- Langflow submitted PR #9441("Add environment variables to allow user control") and added a warning that "In v1.7, credentials will be automatically disabled when using wildcard sources".
• September 25, 2025-- Langflow 1.6.0 released: introduced environment variables to customize CORS allowed sources. However, the default configuration is still vulnerable.
• September 26, 2025--Request for an update on HackerOne's progress.
• October 3, 2025-- DataStax replied, "It's a team thing."
• October 22, 2025- There are still no updates on GitHub security; VulnCheck has been requested to assign a CVE number.
• October 23, 2025--CVE-2025-34291 Vulnerability has been assigned. Thanks to the VulnCheck team for the quick CVE help.
• November 4, 2025--Four months passed, and since users could manually mitigate the problem by adjusting the CORS configuration, we decided to publish this study.

Security researchers at Obsidian Security have discovered a chain of serious vulnerabilities in Langflow