critical

CVE

CVE-2025-34291

CWE

CWE-346

Affected Surface

langflow PyPI package versions through 1.6.9, Langflow deployments using wildcard CORS with credentialed requests, Langflow deployments with refresh_token_lf cookies set SameSite=None, Self-hosted AI agent workflow platforms exposing Langflow sessions to browser users, Langflow workspaces storing API keys, database credentials, model provider tokens, or cloud credentials

CISA added CVE-2025-34291 to the Known Exploited Vulnerabilities catalog on 21 May 2026. The vulnerability affects Langflow, the Python/FastAPI-based visual framework for building AI agents and workflows. The affected package is langflow on PyPI, with vulnerable versions through 1.6.9.

The issue is a chain, not one isolated bug. A permissive CORS policy allows credentialed cross-origin requests, the refresh-token cookie is sent in cross-site contexts, and Langflow exposes authenticated functionality that can execute Python code as part of workflow validation and custom components.

That combination changes a browser visit into application compromise:

victim has an active Langflow session
  -> victim visits attacker-controlled page
  -> browser sends refresh_token_lf to /api/v1/refresh
  -> attacker reads fresh access_token and refresh_token
  -> attacker calls authenticated Langflow APIs
  -> code-execution functionality runs in the Langflow server context

Affected package

The affected package is langflow:

  • Vulnerable: langflow <= 1.6.9
  • Fixed line: langflow >= 1.7.0
  • Current hardening target from the project during this research run: upgrade to the latest stable release, including 1.9.3

The practical exposure is configuration-sensitive, but the vulnerable defaults are what made the chain exploitable. Obsidian and VulnCheck describe the risky configuration as:

allow_origins = ["*"]
allow_credentials = True

combined with a refresh cookie that behaves like:

Set-Cookie: refresh_token_lf=...; SameSite=None; Secure

If a browser is allowed to send that cookie from an attacker-controlled origin and the response is readable through CORS, the attacker can convert a CSRF-like request into token theft.

The vulnerable refresh path

The important endpoint is:

POST /api/v1/refresh

The endpoint trusts the refresh token cookie as its authentication mechanism. With SameSite=None, browsers include refresh_token_lf on cross-site requests over HTTPS. With wildcard credentialed CORS, the attacker’s page can read the JSON response containing fresh tokens.

A simplified exploit flow looks like this:

const response = await fetch('https://langflow.example.com/api/v1/refresh', {
  method: 'POST',
  credentials: 'include',
});

const tokens = await response.json();

In a secure deployment, that request should fail for at least one reason: the browser should not send the cookie cross-site, the origin should not be allowed, or the refresh endpoint should require an anti-CSRF value unavailable to the attacker. The vulnerable chain allows the request and exposes the response.

Why token theft becomes RCE

Langflow had already moved the high-risk /api/v1/validate/code style paths behind authentication after earlier RCE work. CVE-2025-34291 bypasses that security boundary by obtaining a valid token from the victim’s browser.

Obsidian’s analysis describes the core code-execution surface as Python code validation for custom components. The dangerous pattern is that validating Python functions can still execute Python constructs such as default arguments and decorators. In a workflow-builder product, authenticated code execution may be an intended feature, but authentication becomes the only wall between a browser-based token hijack and server-side code execution.

The impact is larger than the Langflow process. Langflow workspaces commonly store provider API keys, database credentials, SaaS tokens, vector database credentials, cloud secrets, and internal workflow data. Once the attacker gets code execution or API access inside the workspace, those connected systems can become the real blast radius.

Exploitation signal

CISA’s KEV entry is the strongest prioritization signal for defenders. CrowdSec also reported active exploitation beginning in January 2026 and noted an attribution challenge specific to this bug: because requests are emitted by the victim’s browser, defender logs often show residential or legitimate user IPs rather than attacker infrastructure.

That means IP-based blocking is not enough. A successful exploit can look like a valid user session calling /api/v1/refresh, followed by normal authenticated API use from the victim’s browser context or from freshly stolen tokens.

What to look for

Prioritize externally reachable and internally shared Langflow instances, especially ones used for AI experimentation, workflow automation, or internal tooling.

Configuration checks:

python -m pip show langflow
env | rg '^LANGFLOW_CORS|^LANGFLOW_REFRESH'

Risky values include:

LANGFLOW_CORS_ORIGINS=*
LANGFLOW_CORS_ALLOW_CREDENTIALS=true
LANGFLOW_REFRESH_SAME_SITE=none

Response investigation should include:

  • Access logs for cross-origin POST /api/v1/refresh requests.
  • Origin headers that do not match approved frontend hosts.
  • Token refresh bursts followed by /api/v1/validate/code or custom-component validation calls.
  • New or changed flows that include suspicious Python code.
  • Reads of workspace variables, API keys, or integration secrets after unusual refresh activity.
  • Outbound network connections from the Langflow server after authenticated code validation.

Because the exploit relies on a logged-in browser, user education and phishing controls help, but they are not sufficient. The application must enforce origin and CSRF boundaries itself.

Remediation

Upgrade Langflow. Use at least 1.7.0, and prefer the latest stable release after verifying compatibility:

python -m pip install --upgrade langflow
python -m pip show langflow

For container deployments:

docker pull langflowai/langflow:1.9.3

Then harden the deployment configuration explicitly:

export LANGFLOW_CORS_ORIGINS="https://app.example.com,https://langflow.example.com"
export LANGFLOW_CORS_ALLOW_CREDENTIALS=true
export LANGFLOW_REFRESH_SAME_SITE=lax

If wildcard origins are unavoidable in a non-production environment, do not allow credentialed requests:

export LANGFLOW_CORS_ORIGINS="*"
export LANGFLOW_CORS_ALLOW_CREDENTIALS=false

Production deployments should avoid default credentials, isolate Langflow from untrusted browser origins, and treat stored workflow variables as secrets. If exploitation is suspected, rotate:

  • Langflow user credentials and API keys.
  • Model provider keys.
  • Database credentials.
  • Vector store credentials.
  • SaaS and cloud tokens stored in workspace variables.
  • Any secret reachable from the Langflow server process environment.

Also review whether code-execution features are necessary for each deployment. If Langflow is used only for non-code workflows, restrict or isolate custom-component validation and execution paths behind additional controls.

References