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/{flowid}/vertices (retrieveverticesorder) - POST /api/v1/build/{flowid}/vertices/{vertexid} (buildvertex)

Any authenticated user who knows (or obtains) another user's flowid 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, includeinschema=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/{flowid}/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:

- retrieveverticesorder (src/backend/base/langflow/api/v1/chat.py, lines 81-159 in 1.9.1) only required authentication via dependencies=[Depends(getcurrentactiveuser)]. The user was never injected into the handler, and the flow was loaded with buildgraphfromdb(flowid=flowid, ...). - buildvertex (chat.py, lines 320-491 in 1.9.1) receives currentuser, but only uses it for variable resolution (userid=str(currentuser.id)). It is never used to scope the flow lookup. The graph is taken from the chat-service cache keyed by flowid, or rebuilt with buildgraphfromdb on a cache miss. - buildgraphfromdbnocache (src/backend/base/langflow/api/utils/flowutils.py) does a bare primary-key lookup, session.get(Flow, flowid), with no owner filter.

The supported replacement, POST /api/v1/build/{flowid}/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 readflow fix for GHSA-8c4j-f57c-35cf.

Additional side effects in affected versions:

- retrieveverticesorder stores the graph in the chat-service cache under the victim's flowid (chatservice.setcache(str(flowid), graph)). When the request includes a data body, the cached graph is attacker-supplied. - buildvertex schedules logvertexbuild for the victim's flowid, 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

1. The attacker authenticates as any valid user. 2. The attacker obtains a victim flowid (shared URLs, exported flow files, logs, screenshots, etc.). 3. POST /api/v1/build/{victimflowid}/vertices returns 200 OK with {"ids": [...], "runid": "...", "verticestorun": [...]} listing the victim flow's vertex IDs (component type plus suffix, e.g. ChatInput-abc12). 4. The attacker calls POST /api/v1/build/{victimflowid}/vertices/{vertexid} 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 userid. - 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 flowid. 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/{victimflowid}/vertices | 404 Not Found | 200 OK with vertex order payload | | Attacker → POST /api/v1/build/{victimflowid}/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/testendpoints.py:

- testgetverticesreturns404forotherusersprivateflow - testgetverticeswithsupplieddatareturns404forotherusersprivateflow - testbuildvertexreturns404forotherusersprivateflow

Patches

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

1. inject currentuser (for retrieveverticesorder, this replaces the dependencies-only declaration), 2. 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 3. call ensureflowpermission(currentuser, FlowAction.EXECUTE, ...) before building or caching any graph.

python retrieveverticesorder / buildvertex (1.10.1) stmt = ( select(Flow) .where(Flow.id == flowid) .where((Flow.userid == currentuser.id) | (Flow.accesstype == AccessTypeEnum.PUBLIC)) ) flow = (await session.exec(stmt)).first() if not flow: raise HTTPException(statuscode=404, detail=f"Flow with id {flowid} not found") await ensureflowpermission( currentuser, FlowAction.EXECUTE, flowid=flowid, flowuserid=flow.userid, workspaceid=flow.workspaceid, folderid=flow.folderid, )

Related hardening in later releases:

- #14342 (1.11.2) applies the same guard to the sibling GET /api/v1/build/{flowid}/{vertexid}/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.

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/{servername}) 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 LANGFLOWAUTOLOGIN=true, GET /api/v1/autologin hands out a token without credentials, so on an exposed instance running the default configuration this is reachable without an account. AUTOLOGIN 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 {commandstr} ..." 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.validatemcpstdioconfig) 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.connecttoserver, before 1.10.3):

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

commandstr is built from the user's command + args. The only "validation" before 1.9.0 was validatenodeinstallation, which only checks that Node.js is installed when the command contains npx. The MCP SDK then starts the process with anyio.openprocess, 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 autologin (default configuration):

bash TOKEN=$(curl -s http://127.0.0.1:7860/api/v1/autologin | python3 -c 'import sys,json;print(json.load(sys.stdin)["accesstoken"])')

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/pwnedlangflow"]}'

/tmp/pwnedlangflow 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.connecttoserver("touch /tmp/pwnedlangflow") 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 (LDPRELOAD, NODEOPTIONS, PYTHONPATH, BASHENV, ...), and Docker isolation checks. - #14036 (1.10.3) — moves the policy into lfx.base.mcp.security.validatemcpstdioconfig 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:

python commandparts = shlex.split(commandstr) command, args = commandparts[0], commandparts[1:] validatemcpstdioconfig(command, args, env) # final pre-spawn enforcement serverparams = StdioServerParameters(command=command, args=finalargs, env=envdata)

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

Workarounds (if you cannot upgrade)

- Set LANGFLOWAUTOLOGIN=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:

- LANGFLOWMCPSERVERALLOWEDPACKAGES — the exact packages npx / uvx may run. - LANGFLOWMCPSERVERINTERPRETERHARDENING=true and LANGFLOWMCPSERVERDOCKERHARDENING=true. - On 1.11.1+ (#14150), restricting custom code (LANGFLOWALLOWCUSTOMCOMPONENTS=false, LANGFLOWCUSTOMCOMPONENTADMINONLY=true or LANGFLOWBLOCKCODEINTERPRETERCOMPONENTS=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 AUTOLOGIN. The reporter found several internet-facing Langflow servers that were vulnerable.