Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
36 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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…
Recommended action: Upgrade to 1.10.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 1.10.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Langflow's project-scoped MCP transport authenticates the caller for the projectid 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: 1. src/backend/base/langflow/api/v1/mcpprojects.py:147-193 verifyprojectauthconditional() authenticates the caller and…
Recommended action: Upgrade to 1.9.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Summary An IP spoofing vulnerability in the Model Context Protocol (MCP) configuration installation endpoint (POST /api/v1/mcp/project/{projectid}/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 getclientip helper, used to enforce the local-only gate for installmcpconfig. 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/mcpprojects.py Correction vs. the original report: the request body accepted by this endpoint is…
Recommended action: Upgrade to 1.10.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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: 1. Protection disabled / warn-only. The SSRF guard (lfx/utils/ssrfprotection.py, added in 1.7.0 by #10544) shipped with ssrfprotectionenabled = False, and its only caller, the API Request component, called validateurlforssrf(url, warnonly=True). So even with protection turned on, blocked URLs were only logged. 2. 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,…
Recommended action: Upgrade to 1.10.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 issuperuser) 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…
Recommended action: Upgrade to 1.10.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Langflow uses Python's random module (Mersenne Twister, a non-cryptographic PRNG) seeded with the SECRETKEY to derive the Fernet encryption key for all stored user credentials (API keys, LLM provider secrets, database passwords). When the SECRETKEY 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 SECRETKEY (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 SECRETKEY is 32+ characters (the "safe" branch), the raw key material is used directly as the Fernet key — meaning exfiltrating the secretkey 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:…
Recommended action: Upgrade to 1.10.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 WEBHOOKAUTHENABLE 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 WEBHOOKAUTHENABLE setting was introduced in v1.7.0 (#9139) with a default of False. The root cause is in the webhook authentication path, AuthService.getwebhookuser (src/backend/base/langflow/services/auth/service.py; the thin wrapper in src/backend/base/langflow/services/auth/utils.py just delegates to it): By default (v1.7.0 through v1.9.0), Langflow treats WEBHOOKAUTHENABLE as False, meaning all webhook endpoints are public. This relies exclusively on the secrecy of the flowid (UUID), which is an insecure practice (Security by Obscurity). A related report,…
Recommended action: Upgrade to 1.9.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
###Summary: A critical Authenticated Remote Code Execution (RCE) vulnerability exists in the validatecode 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 validatecode function parses user input using ast. When it encounters a FunctionDef node, it compiles and executes it to check for extensive errors: 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…
Recommended action: Upgrade to 1.10.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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/llmoperations/lambdafilter.py (line 242 in v1.10.2) For example, an attacker can attempt to make the model return: lambda x:…
Recommended action: Upgrade to 1.10.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
IBM Langflow OSS 1.0.0 through 1.10.0 allows authenticated attackers to execute arbitrary OS commands and read sensitive files including credentials, enabling complete system compromise and lateral movement.
Recommended action: Upgrade to 1.10.1rc0 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
All components based on BaseFileComponent are vulnerable to the following vulnerability: 1. Docling (DoclingInlineComponent) 2. Docling Serve (DoclingRemoteComponent) 3. Read File (FileComponent) 4. NVIDIA Retriever Extraction (NvidiaIngestComponent) 5. Video File (VideoFileComponent) 6. Unstructured API (UnstructuredComponent) For clarity, from now on I'll only refer to Read File component. The Read File node processes user-controlled files. Example scenario is a RAG chatbot - a system that allows users of an organization to ask questions about documents saved in the organizations. By controlling a files that are digested into the RAG, an attacker can direct the node to read any file on the file-system by absolute path. Using this vulnerability an attacker can acheive RCE: 1. Upload a file that directs the node to read Langflow's secretkey file containing the JWT token secret. 2. This would allow the attacker then to simply task the Chatbot for the JWT secret. 3. Using this…
Recommended action: Upgrade to 1.9.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An attacker can send a /api/v1/files/upload/ request without any authentication token/cookies and abuse a very long multipart form boundary to make the langflow app unusable for all users for an indefinite amount of time. Details https://github.com/langflow-ai/langflow/blob/v1.0.18/src/backend/base/langflow/api/v1/files.py#L40 The file upload function will try to process the multipart form data even if it is malformed and contains a payload such as an extremely large amount of hyphens after the boundary. It also does not do the authentication check before trying to process this data so an unauthenticated attacker can perform this as well as authenticated users. Additionally, an attacker doesn't even need to know a valid UUID of a flow to send this request because the server will still try to process the large boundary even with any random value in place of the flow ID. PoC An attacker makes this request to upload a file without valid authentication information or a valid flow…
Recommended action: Upgrade to 1.0.19 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The logout button does not clear the session. The previous user stays logged in unless another user explicitly logs in. Details Not in auto login mode. Hosted on localhost. accesstokenlf remains present in both Local Storage and Cookies. refreshtokenlf remains present in Cookies. Root cause: the /logout endpoint deleted the authentication cookies without matching the original httponly/samesite/secure/domain parameters, so the browser kept them; additionally the frontend did not clear the auth cookies on logout. PoC Click Logout. Hit refresh to return to previous screen. Impact Users on shared computers may falsely believe they have terminated their session. Patches Fixed in 1.7.0 (PRs #10527 and #10528). The logout endpoint now deletes the auth cookies using the same parameters they were created with, and the frontend clears the auth cookies on logout. Upgrade to 1.7.0 or later.
Recommended action: Upgrade to 1.7.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Insecure Direct Object Reference (IDOR) vulnerability in /api/v1/responses endpoint allows an authenticated attacker to execute any flow belonging to another user by specifying the victim's flow ID in the request. Details The vulnerability exists in the getflowbyidorendpointname helper function in src/backend/base/langflow/helpers/flow.py (lines 399-414). When a flow is accessed via UUID (flowid), the function queries the database directly without verifying if the authenticated user owns that flow: This function is used by the /api/v1/responses endpoint (defined in src/backend/base/langflow/api/v1/openairesponses.py:589). PoC (Proof of Concept) Impact Any authenticated user can: 1. Execute any flow in the system by knowing its flow ID 2. Access potentially sensitive data processed by victim's flows 3. Consume victim's resources Fixes Fixed in PR #12832 (fix(security): close IDOR in getflowbyidorendpointname), merged 2026-04-22, released in Langflow 1.9.1. The helper…
Recommended action: Upgrade to 1.9.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Unauthenticated users can upload any amount of data to the server without any limitations. No need for any prior knowledge, only network access to Langflow. This can lead to space exhaustion on the server. In adition, in the response, the absolute path of the uploaded file is reported to the attacker, which is an information leak that can assist in chaining other primitives. Tested on commit 2d67402b1dbaefcbce85a244d4a6cd5e4bda1cfe Details Code is in langflow/api/v1/endpoints.py: As can be seen above, there is no authentication. There is not validation over flowid as well, unlike other endpoints: Function saveuploadedfile saves the file to local file-system. Suggested fix: 1. Add authentication to route. 2. Only return relative path or filename. PoC PoC: Example: Impact 1. Space exhaustion on server that can lead to Denial-of-Service. 2. Information leak - leakage of absolute path of langflow's cache directory in server. Patches Fixed in 1.9.1 via PR #12831. The deprecated…
Recommended action: Upgrade to 1.9.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The "Shareable Playground" (or "Public Flows" in code) contains a potential arbitrary file-read vulnerability, depending on the exact flow configuration used. By making a flow public, public execution of the flow is allowed. The execution request can contain a list of files that gets read by Langflow and fed into the LLM. The files path can be any path supported by the storage - it can be either a local file or S3 path if supported by the local configuration Details Shareable Playground feature works by enabling the execution of workflows by unauthenticated users, by accessing a link. Specifically, it enables the route /api/v1/buildpublictmp to execute any public flow, given a public flow ID. This request contains a files field that can contain a list of files. The files get read in LCModelComponent.getchatresult in a call to tolcmessage. A detailed stacktrace: This triggers Langflow to feed the file into the LLM as an Image. Reading the files back depends on the specific LLM…
Recommended action: Upgrade to 1.10.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The "Shareable Playground" (or "Public Flows" in code) contains a critical RCE vulnerability. Simply sharing a flow exposes the deployment to RCE risk by authenticated users. Tested on commit 2d67402b1dbaefcbce85a244d4a6cd5e4bda1cfe Details Shareable Playground feature works by enabling the execution of workflows by unauthenticated users, by accessing a link. Specifically, it enables the route /api/v1/buildpublictmp to execute any public flow, given a public flow ID. When the route executes the flow, it allows for providing arbitrary custom Python code as the nodes code, inside the JSON payload! The vulnerable field is data.nodes[X].data.node.template.code.value. See PoC for an example. PoC Reproduction: 1. Create a new flow and add a Chat Input node to it 2. Share the flow ("Shareable Playground") 3. Access the public link with the browser developers tools open and execute the flow. 4. Find the /api/v1/buildpublictmp route and copy as cURL 5. Edit the…
Recommended action: Upgrade to 1.9.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Langflow is vulnerable to Path Traversal in the Knowledge Bases API (POST /api/v1/knowledgebases). This occurs because user-supplied knowledge base names are used directly to create file paths without proper sanitization or containment checks. An authenticated attacker can exploit this flaw to create directories and write files anywhere on the server's filesystem. Details The vulnerability exists in the createknowledgebase function within src/backend/base/langflow/api/v1/knowledgebases.py. This function constructs file paths directly from the user-supplied name field without sanitization. The value is concatenated with the user's base directory and passed directly to kbpath.mkdir(). Immediately following the directory creation, the application writes embeddingmetadata.json and schema.json into this attacker-controlled path. PoC (Proof of Concept) For the Create endpoint, an attacker can supply traversal sequences or absolute paths in the name field: ../victimuser/evilkb or…
Recommended action: Upgrade to 1.9.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Langflow's /api/v1/monitor router exposes 7 endpoints that perform read, write, and delete operations on user-owned resources — messages, sessions, build artifacts, and LLM transaction logs — without verifying that the authenticated requester owns the targeted resource. Any authenticated user can read, modify, rename, or permanently delete another user's data by supplying the target's resource ID or flowid. This is a classic IDOR/BOLA vulnerability. Notably, the same source file (monitor.py) contains one correctly-implemented endpoint that uses an ownership check, demonstrating the correct pattern was known but inconsistently applied. Details Source file: src/backend/base/langflow/api/v1/monitor.py The correct pattern (used only in GET /monitor/messages, lines 77–80): All 7 vulnerable endpoints are missing this guard: 1. GET /api/v1/monitor/builds (lines 27–33) — reads build data for any flowid: 2. DELETE /api/v1/monitor/messages (lines 102–107) — deletes any message by UUID:…
Recommended action: Upgrade to 1.9.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Langflow is vulnerable to Path Traversal in the Knowledge Bases API (DELETE /api/v1/knowledgebases). This occurs because user-supplied knowledge base names are concatenated directly into file paths without proper sanitization or boundary validation. An authenticated attacker can exploit this flaw to delete arbitrary directories anywhere on the server's filesystem, leading to data loss and potential service disruption. Details The vulnerability exists in the deleteknowledgebasesbulk function within src/backend/base/langflow/api/v1/knowledgebases.py. This function constructs file paths directly from the user-supplied kbnames parameter. While other knowledge base endpoints safely route through standard path resolution (e.g., resolvekbpath()), the bulk delete handler bypasses this entirely. It builds the path manually and passes it directly to shutil.rmtree() without validating if the resulting path resolves outside the intended user directory. PoC (Proof of Concept) For the Bulk…
Recommended action: Upgrade to 1.9.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A security vulnerability has been detected in langflow-ai langflow up to 1.8.3. The affected element is the function createproject/encryptauthsettings of the file src/backend/base/Langflow/api/v1/projects.py of the component Project Creation Endpoint. Such manipulation of the argument authsettings leads to cleartext storage in a file or on disk. The attack can be launched remotely. The exploit has been disclosed publicly and may be used. The vendor was contacted early about this disclosure but did not respond in any way.
Recommended action: Upgrade to 1.9.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Vulnerability IDOR in GET/PATCH/DELETE /api/v1/flow/{flowid} The readflow helper in src/backend/base/langflow/api/v1/flows.py branched on the AUTOLOGIN setting to decide whether to filter by userid. When AUTOLOGIN 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 userid = NULL) under auto-login mode, but inadvertently left the authenticated path without an ownership filter. --- Fix (PR #8956) The fix removes the AUTOLOGIN conditional entirely and unconditionally scopes the query to the requesting user: All three operations — read, update, and delete —…
Recommended action: Upgrade to 1.5.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
1. Summary The Agentic Assistant feature in Langflow executes LLM-generated Python code during its validation phase. Although this phase appears intended to validate generated component code, the implementation reaches dynamic execution sinks and instantiates the generated class server-side. In deployments where an attacker can access the Agentic Assistant feature and influence the model output, this can result in arbitrary server-side Python execution. 2. Description 2.1 Intended Functionality The Agentic Assistant endpoints are designed to help users generate and validate components for a flow. Users can submit requests to the assistant, which returns candidate component code for further processing. A reasonable security expectation is that validation should treat model output as untrusted text and perform only static or side-effect-free checks. The externally reachable endpoints are:…
Recommended action: Upgrade to 1.9.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Vulnerability Path Traversal in GET /api/v1/files/profilepictures/{foldername}/{filename} The downloadprofilepicture function in src/backend/base/langflow/api/v1/files.py constructed file paths by directly concatenating the user-supplied foldername and filename path parameters without sanitization or boundary validation. The resulting path was passed to the filesystem without verifying it remained within the intended directory. An unauthenticated attacker could supply traversal sequences (e.g. ../secretkey) to navigate outside the profile pictures directory and read arbitrary files on the server filesystem. This exposed the server to: - Sensitive file disclosure — any file readable by the application process could be retrieved - Secret key exfiltration — the application's secretkey file, used as JWT signing material, could be read directly via ../secretkey - Authentication bypass — with the secretkey in hand, an attacker can forge valid JWT tokens and authenticate as any user,…
Recommended action: Upgrade to 1.7.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.