← Back to Feed CACHED · 2026-06-30 20:11:44 · CACHE_KEY CVE-2026-33017
CVE-2026-33017 · CWE-94 · Disclosed 2026-03-17

Langflow has Unauthenticated Remote Code Execution via Public Flow Build Endpoint

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
Do you agree?
01 · The Real Story

A public 'build this flow' button that runs whatever Python you paste into it

Langflow exposes POST /api/v1/build_public_tmp/{flow_id}/flow so that anonymous users can render public flows in the visual builder. The handler accepts attacker-supplied node definitions and instantiates them server-side — meaning arbitrary Python embedded in node code, default arguments, or decorators is exec()'d in the Langflow worker process with whatever privileges the service runs as (usually the container's root or the host's langflow user). All versions ≤ 1.8.2 are affected; the fix lands in 1.9.0, which adds authentication and input validation on the public-build path. This is the second time the same exec() pattern has bitten Langflow — CVE-2025-3248 was the first round on /api/v1/validate/code.

Vendor severity (CRITICAL / 9.3) is accurate and arguably understated. CVSS 4.0 captures the trivial reachability (AV:N/AC:L/PR:N/UI:N) but the real-world story is worse: KEV listing, EPSS 0.984, observed mass scanning, Monero miner payloads in the wild within 20 hours of advisory publication, and a target population (Langflow servers) that is almost always internet-exposed by design because operators want their RAG agents reachable. There is no friction to audit away.

"Unauthenticated RCE on an internet-exposed AI orchestration server, KEV-listed, exploited within 20 hours of disclosure. Patch now."
02 · The Attack Path

5 steps from start to impact.

STEP 01

Discover exposed Langflow instance

Attacker fingerprints Langflow by the /health, /api/v1/version, or the default :7860 UI banner. Shodan, Censys, and FOFA all have ready-made queries (http.title:"Langflow", http.favicon.hash). Mass scanning is already happening — Sysdig observed it within 20 hours of disclosure.
Conditions required:
  • Langflow instance reachable on TCP (typically 7860 or behind a reverse proxy on 80/443)
  • No IP allowlist or auth proxy in front
Where this breaks in practice:
  • None for cloud-hosted demos and SaaS deployments of customer agents
  • Internal-only deployments behind a VPN are unreachable
Detection/coverage: Shodan/Censys/FOFA fingerprints are public; GreyNoise tags Langflow RCE Attempt as of March 2026
STEP 02

Craft malicious flow JSON

Attacker constructs a flow JSON whose node definitions embed Python code in custom component fields, default argument expressions, or decorator metadata. Public PoCs (RAXE Labs advisory, Aviral Srivastava's writeup) provide working payloads. Typical payload uses __import__('os').system(...) inside a class default value.
Conditions required:
  • Knowledge of Langflow node schema (publicly documented)
  • No PoC needed — advisory text alone is enough; attackers wrote exploits from it in hours
Where this breaks in practice:
  • None — payload is plain JSON, no auth, no CSRF token
Detection/coverage: WAF rules for __import__, subprocess, os.system inside JSON bodies posted to /api/v1/build_public_tmp/
STEP 03

POST to the public build endpoint

Single unauthenticated POST /api/v1/build_public_tmp/{flow_id}/flow with the crafted JSON body. The server deserializes the flow and calls exec() on attacker-controlled code paths before any authorization check runs. Tooling: curl, httpx, or the public Nuclei template langflow-rce-cve-2026-33017.yaml.
Conditions required:
  • Reachable endpoint
  • Any flow_id (endpoint accepts arbitrary IDs in the vulnerable path)
Where this breaks in practice:
  • None at the protocol layer; a fronting reverse proxy that blocks /api/v1/build_public_tmp/* would stop it
Detection/coverage: Nuclei template available; Sysdig Falco rule Langflow Public Build RCE released March 2026
STEP 04

Code execution as the Langflow process

Payload runs in the Langflow Python worker. In container deployments this is usually UID 0 inside the container; on bare-metal it is the langflow service account. Attackers gain shell access, read .env (OpenAI/Anthropic/Azure keys, DB creds), and pivot.
Conditions required:
  • No egress restrictions on the Langflow host (reverse shell)
  • Service has read access to its own config and secrets
Where this breaks in practice:
  • egress firewall blocking outbound to attacker C2
  • read-only root filesystem
  • non-root container user with restricted capabilities
Detection/coverage: EDR catches python spawning sh/curl/wget to non-vendor IPs; cloud workload-protection flags Monero miner binaries
STEP 05

Persistence and payload drop

Observed in-the-wild payload: a customized XMRig Monero miner pulled from attacker infra, persisted via cron or systemd. Sysdig also observed credential harvesting from the Langflow config directory and lateral movement into the orchestration layer (LangChain backends, vector DBs).
Conditions required:
  • Outbound internet from victim
  • Write access to /tmp or a persistence path
Where this breaks in practice:
  • Egress firewalling to known-bad IPs
  • CSPM detecting privilege change on the container
Detection/coverage: XMRig hashes are well-known to every major EDR/AV; CPU spike alerting
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusActive mass exploitation — Sysdig TRT observed first attempts within 20 hours of advisory publication (March 17, 2026)
KEV statusListed — CISA KEV catalog, federal patch-by deadline April 8, 2026
EPSS0.98412 (≥99th percentile — top tier exploitability)
Public PoCWorking exploits in the RAXE Labs advisory, Aviral Srivastava's Medium/Dev.to writeups, and a public Nuclei template
CVSS4.0 vector AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:L/SI:L/SA:L — unauthenticated network attack, no user interaction, full CIA on the host
Affected versionsLangflow ≤ 1.8.2 (all prior releases vulnerable)
Fixed version1.9.0 (adds auth + validation on public build path)
Exposure dataShodan/Censys show several thousand Langflow instances internet-facing; GreyNoise tag Langflow RCE Attempt active since March 2026
Observed payloadCustomized XMRig Monero miner, credential harvesting from .env, reverse shells (Sysdig, GBHackers)
Disclosed2026-03-17 via GHSA-vwmf-pq79-vjvx; reported by Aviral Srivastava
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to CRITICAL (9.6/10)

This is unauthenticated RCE on an internet-exposed AI orchestration server that is actively being exploited in the wild and KEV-listed — the single most decisive factor is the combination of zero auth requirement and confirmed mass exploitation with EPSS 0.984. There is no friction to audit away: one HTTP POST achieves code execution as the Langflow service account.

HIGH Exploitation confirmed in the wild
HIGH Affected version range
HIGH Patch availability and effectiveness

Why this verdict

  • Unauthenticated and pre-auth reachable — no credentials, no session, no user interaction; a single POST to /api/v1/build_public_tmp/{flow_id}/flow is the entire chain
  • KEV-listed with EPSS 0.984 — CISA flagged it within weeks of disclosure; federal patch deadline already issued
  • Active exploitation within 20 hours of advisory publication (Sysdig TRT), with XMRig miner payloads and credential theft already observed
  • Role multiplier: Langflow hosts the orchestration plane for RAG/agent pipelines — code execution there yields API keys (OpenAI/Anthropic/Azure), vector DB credentials, and access to enterprise data sources feeding the agents. Even on a 'low-value' dev instance the blast radius reaches the model-provider billing account and any data the agent retrieves
  • Role multiplier: in production AI-agent deployments Langflow sits adjacent to internal data stores (Postgres, S3, Snowflake connectors) — the chain ends in enterprise data egress, not just one host
  • Internet-exposure is the design pattern — operators deploy Langflow to serve agents; the assumption that 'most instances are internal' does not hold here as it does for ESXi or DCs

Why not higher?

CRITICAL is already the top bucket. We score 9.6 rather than the 10.0 ceiling because the immediate blast radius is the Langflow process itself — fleet-scale impact requires the secrets and connectors that the box holds, which is high-probability but not automatic.

Why not lower?

Downgrading to HIGH would require either authentication friction, an exposure population below 1%, or a containment story (sandboxing, non-root execution) — none apply. Langflow is deployed to be reachable, the endpoint is anonymous, and the code runs in the main worker. The KEV listing and EPSS 0.984 alone make a sub-CRITICAL call indefensible.

05 · Compensating Control

What to do — in priority order.

  1. Block the public build endpoint at the reverse proxy NOW — Add a deny rule for ^/api/v1/build_public_tmp/ on your nginx/Traefik/ALB in front of Langflow until you can deploy 1.9.0. This is the surest pre-patch mitigation and ships in under an hour. Per noisgate mitigation SLA for CRITICAL + active KEV exploitation: deploy within hours, not days.
  2. Take internet-exposed Langflow instances offline or behind VPN — If you cannot patch within hours, pull the Langflow ingress from the public internet and re-front it with an auth proxy (Cloudflare Access, Pomerium, oauth2-proxy). Active mass exploitation means every hour of public exposure is a live compromise window.
  3. Egress-restrict Langflow workers — Outbound allowlist to only the model-provider APIs you actually use (api.openai.com, api.anthropic.com, your vector DB). Kills the miner-download and reverse-shell steps even if RCE lands. Apply within the mitigation window (hours), keep permanently.
  4. Rotate all secrets held by Langflow — If your instance was internet-facing for any window after March 17, 2026, assume compromise. Rotate OpenAI/Anthropic/Azure keys, DB creds, and any OAuth client secrets stored in Langflow's .env or component configs. Do this in parallel with patching, not after.
  5. Hunt for indicators — Check for outbound to known XMRig pools, unusual python child processes (sh, curl, wget), and recent writes to /tmp or ~/.cache on Langflow hosts. Sysdig and SonicWall have published IOCs; ingest them into your SIEM.
What doesn't work
  • WAF generic rules — payload is JSON with Python keywords; signature WAFs without Langflow-specific rules will miss it
  • Authentication on the UI login page — the vulnerable endpoint bypasses login by design; adding admin auth to /login does nothing
  • Network segmentation alone — if any production data source is reachable from the Langflow host (your vector DB, your S3 bucket), segmentation downstream of Langflow is the wrong layer
  • Running Langflow as non-root inside the container — useful for host escape but does not stop secret theft or model-provider key abuse
06 · Verification

Crowdsourced verification payload.

Run on an auditor workstation or CI runner with network reach to the Langflow host. Usage: ./check_langflow.sh https://langflow.example.com. No privileges required; only outbound HTTP to the target.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/usr/bin/env bash
# noisgate verifier for CVE-2026-33017 (Langflow unauthenticated RCE)
# Outputs: VULNERABLE | PATCHED | UNKNOWN
set -u

TARGET="${1:-}"
if [[ -z "$TARGET" ]]; then
  echo "usage: $0 <https://langflow-host>" >&2
  exit 2
fi

# 1. Try to read the version endpoint (unauth on all versions)
VER_JSON="$(curl -sk --max-time 10 "$TARGET/api/v1/version" || true)"
VERSION="$(echo "$VER_JSON" | grep -oE '"version"[[:space:]]*:[[:space:]]*"[^"]+"' | head -1 | sed -E 's/.*"([^"]+)"$/\1/')"

if [[ -n "$VERSION" ]]; then
  # semver compare against 1.9.0
  IFS='.' read -r MAJ MIN PAT <<<"${VERSION%%[-+]*}"
  MAJ=${MAJ:-0}; MIN=${MIN:-0}; PAT=${PAT:-0}
  if (( MAJ > 1 )) || { (( MAJ == 1 )) && (( MIN >= 9 )); }; then
    echo "PATCHED (version $VERSION >= 1.9.0)"
    exit 0
  else
    echo "VULNERABLE (version $VERSION < 1.9.0)"
    exit 1
  fi
fi

# 2. Fallback: probe the vulnerable endpoint with a benign payload
#    A 200/422 (request reached the handler) on an unauthenticated POST
#    to build_public_tmp indicates the public build path is enabled.
PROBE_BODY='{"data":{"nodes":[],"edges":[]}}'
CODE="$(curl -sk -o /dev/null -w '%{http_code}' --max-time 10 \
  -X POST -H 'Content-Type: application/json' \
  -d "$PROBE_BODY" \
  "$TARGET/api/v1/build_public_tmp/00000000-0000-0000-0000-000000000000/flow" || true)"

case "$CODE" in
  200|202|400|422)
    echo "VULNERABLE (public build endpoint reachable unauthenticated; HTTP $CODE)"
    exit 1 ;;
  401|403|404)
    echo "PATCHED (public build endpoint not reachable unauthenticated; HTTP $CODE)"
    exit 0 ;;
  *)
    echo "UNKNOWN (HTTP $CODE from build endpoint, no version metadata)"
    exit 3 ;;
esac
07 · Bottom Line

If you remember one thing.

TL;DR
Treat this as a live incident, not a patch ticket. Per noisgate mitigation SLA for a KEV-listed, actively-exploited CRITICAL the deadline is patch or mitigate within hours, not the standard 3-day CRITICAL window — by end of Monday: (1) inventory every Langflow instance (look for port 7860, the /api/v1/version fingerprint, and any container image tagged langflow/langflow:* below 1.9.0), (2) for any internet-facing instance, block /api/v1/build_public_tmp/ at the proxy or pull the ingress entirely, (3) upgrade to 1.9.0+ across the fleet, and (4) rotate every secret the instance held (OpenAI/Anthropic/Azure keys, DB creds, OAuth secrets) because if your box was reachable any time after March 17, 2026, assume it was hit. Per noisgate remediation SLA the vendor patch must be fully deployed within 90 days, but with this EPSS and KEV status the realistic target is end of week. Then hunt: outbound to XMRig pools, python spawning shells, and new cron/systemd persistence on Langflow hosts.

Sources

  1. GitHub Security Advisory GHSA-vwmf-pq79-vjvx
  2. Sysdig — Compromised in 20 hours
  3. SonicWall — Langflow AI Code Injection to RCE
  4. RAXE Labs RAXE-2026-043 advisory
  5. Aviral Srivastava — researcher writeup
  6. The Hacker News — Monero miner exploitation
  7. Wiz vulnerability database — CVE-2026-33017
  8. CSO Online — CISA sounds alarm
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.