Langflow CVE-2026-33017: Unauthenticated exec() Injection Exploited in Under 20 Hours — Three Attack Phases in 48 Hours
A critical (CVSS 9.3) missing-authentication vulnerability in Langflow's public flow build endpoint passes attacker-controlled Python code directly to exec() with zero sandboxing. Disclosed March 17, 2026 — the first exploitation attempts arrived 20 hours later with no public proof-of-concept. CISA has sounded the alarm. If you run Langflow, you need to patch or take your instance offline today.
Dillip Chowdary
Founder & AI Researcher • March 28, 2026
Vulnerability Summary
- CVE-2026-33017 — CVSS 9.3 Critical, affecting Langflow ≤ 1.8.1
- Root cause: no authentication on
POST /api/v1/build_public_tmp/{flow_id}/flow+ arbitrary Python viaexec() - Time-to-exploit: 20 hours from advisory to active exploitation — no PoC needed
- CISA warning issued; three distinct attack phases observed within 48 hours
- Fix: upgrade to Langflow 1.9.0 or disable public flow execution on internet-facing instances
What Langflow Is and Why This Matters
Langflow is an open-source visual builder for LLM-powered applications. Developers use it to construct AI pipelines — RAG systems, agent workflows, document processing chains — by connecting nodes in a graph editor. Each node can contain custom Python code, LLM API calls, vector store queries, or data transformations. Langflow deployments typically run with access to database connections, LLM API keys, vector store credentials, and cloud provider tokens — exactly the credentials an attacker wants.
The tool has been adopted broadly in the AI developer community, including enterprise teams prototyping AI features and data science teams building production-grade document intelligence systems. Many of these deployments are exposed to internal networks or, in some cases, directly to the internet without the hardening that production web services receive.
The Vulnerability: Missing Auth + exec() With No Sandbox
The vulnerable endpoint is POST /api/v1/build_public_tmp/{flow_id}/flow. This endpoint was designed to support building "public" flows — Langflow's feature for sharing pipeline configurations. The endpoint accepts an optional data parameter containing flow node definitions.
The design intent was that this parameter would be used when the stored flow data is unavailable. The implementation flaw is two-layered:
- No authentication: The endpoint does not require a valid session or API key. Any unauthenticated HTTP client can call it.
- Unsandboxed exec(): When the
dataparameter is present, the endpoint uses the attacker-supplied flow data — which can contain arbitrary Python code in node definitions — and executes it via Python's built-inexec()function with full interpreter access and no restrictions on imports, file system access, or network calls.
The combination of no authentication and unsandboxed code execution produces a vulnerability that is trivially weaponizable: any HTTP client that can reach the Langflow API endpoint can achieve full remote code execution as the process user. No session tokens, no CSRF bypasses, no memory corruption — just a POST request with a Python payload.
Three Attack Phases: How Exploitation Unfolded
Sysdig and Cloud Security Alliance researchers documented three distinct attack phases within the first 48 hours of the advisory's publication:
Phase 1 — Automated Nuclei Scanning (Hours 20–21)
Four IP addresses arrived within minutes of each other, all sending identical payloads with a client_id: nuclei-scanner cookie header. Created flows were named nuclei-cve-2026-33017. This phase represents automated pipeline enumeration — scanning tools adapted to exploit the new CVE within hours of publication, confirming which instances were reachable and vulnerable before human operators followed up.
Phase 2 — Custom Python Exploitation (Hours 21–24)
A different attacker operating from IP 83.98.164.238 ran a methodical manual exploitation campaign using python-requests with no user-agent rotation. The kill chain was sequential: directory listing → credential file access (~/.aws/credentials, .env files) → OS fingerprinting → stage-2 payload delivery. This attacker built a custom exploit from the advisory description alone — no public PoC existed at this point.
Phase 3 — Environment Variable Harvesting (Hours 24–30)
IP 173.212.205.251 executed import os; os.environ to dump all environment variables — capturing database connection strings, LLM API keys (OpenAI, Anthropic), cloud provider tokens, and any other secrets set in the Langflow process environment. This phase represents the monetization step: harvesting credentials for resale or direct cloud account abuse.
Why Attackers Didn't Need a PoC
The 20-hour exploitation window — faster than most CVE responses — is explained by the vulnerability's simplicity. The advisory described the vulnerable endpoint, the missing authentication, and the code execution path in enough detail that any developer familiar with Langflow's API could construct a working exploit in minutes. The CVSS 9.3 score and the phrase "code injection" in the advisory description were sufficient signals for experienced threat actors to begin exploitation immediately.
This pattern — advisory description enables immediate weaponization without a PoC — is becoming the norm for AI application framework vulnerabilities. Unlike memory corruption bugs that require careful exploitation engineering, logic bugs in application-layer endpoints (missing auth, unsandboxed eval, path traversal) are exploitable by any competent developer who reads the advisory carefully. The time between disclosure and exploitation for this class of vulnerability is measured in hours, not days.
Securing AI Pipeline Deployments: Architectural Lessons
CVE-2026-33017 is the second major exec()-class vulnerability in Langflow's history — the first was discovered in 2025 through the same endpoint family. The recurrence of this vulnerability pattern in the same codebase reflects a broader challenge in AI tool development: teams building LLM pipeline builders face a genuine tension between the need to execute arbitrary user-defined code (which is the core value proposition) and the need to do so safely.
Several architectural patterns would have prevented or limited this vulnerability:
- Authentication on all execution endpoints: Any endpoint that executes code — regardless of whether the flow is "public" — must require a valid session token. "Public" should mean publicly viewable, not publicly executable.
- Process-level sandboxing: Code execution in AI pipelines should happen in isolated subprocesses with restricted file system access, no network egress to internal services, and resource limits. Python's
subprocesswith dropped privileges, or a container-per-execution model, reduces the blast radius of any code injection. - Restricted import allowlists: Rather than unrestricted
exec(), pipeline execution environments should use AST inspection to allowlist safe imports and block access toos,subprocess,socket, and file operations that are not needed for LLM pipeline logic. - Network segmentation: Langflow instances should not run with direct access to production databases or be reachable from the public internet. An internal-only deployment reduces the attack surface to authenticated internal users.
Immediate Actions
Remediation Steps