CVE-2026-33017: Langflow RCE Exploits Enterprise AI Pipelines

Key Takeaways

• CVE-2026-33017 is a CVSS 9.8 critical unauthenticated remote code execution (RCE) vulnerability affecting Langflow versions 1.8.2 and earlier, exploitable via a single unauthenticated HTTP request.
• Active exploitation began within 20 hours of the advisory’s publication, before any public proof-of-concept existed, demonstrating the speed with which attackers can weaponize disclosures for AI developer tooling [1].
• Attackers systematically exfiltrated AI service credentials — including API keys for OpenAI, Anthropic, and AWS — creating the conditions for lateral movement into connected cloud infrastructure and potential downstream supply chain compromise.
• CISA added CVE-2026-33017 to its Known Exploited Vulnerabilities (KEV) catalog on March 25, 2026, setting an April 8 federal remediation deadline [2].
• JFrog Security Research confirmed that Langflow version 1.8.2, despite being reported as a fix by some sources, remained fully exploitable; the only verified remediation is upgrading to version 1.9.0 or later [3].
• This incident is a concrete example of the AI tooling security gap: development platforms that store high-value credentials and execute code by design are attractive targets but frequently deployed without the hardening applied to production enterprise systems.

Background

Langflow is an open-source, low-code visual framework for building AI agents, retrieval-augmented generation (RAG) pipelines, and multi-model workflows. It provides a drag-and-drop interface for connecting large language model APIs to data sources, external tools, and custom logic, making it popular among teams building agentic systems. With over 145,000 GitHub stars and an active community, Langflow has seen wide adoption among teams building AI systems [1].

The platform’s design reflects its origins as a rapid-prototyping tool. Langflow instances are routinely configured with API credentials for commercial AI services such as OpenAI and Anthropic, cloud provider access keys, and database connection strings — all stored to enable seamless development workflows. This design makes a compromised Langflow instance far more than a code execution target: it can function as a credential vault for a substantial portion of an organization’s AI development stack.

Langflow also introduced a “public flow” feature intended to let teams share AI workflows without requiring authentication. It is this feature’s supporting API endpoint — POST /api/v1/build_public_tmp/{flow_id}/flow — that introduced CVE-2026-33017. The endpoint’s design allows unauthenticated access to execute flow builds, a capability that was intended for sharing purposes but that the implementation failed to protect against attacker-supplied flow data.

The vulnerability was disclosed on March 17, 2026, via a coordinated advisory. The RAXE Labs advisory (RAXE-2026-043) assigned a CVSS v3.1 base score of 9.8 (Critical) [6], reflecting the combination of no authentication requirement, network accessibility, and the potential for complete system compromise. The GitHub security advisory (GHSA-vwmf-pq79-vjvx) independently assessed the vulnerability at 9.3 under the CVSS v4 scoring framework [5].

Security Analysis

Vulnerability Mechanics

The root cause of CVE-2026-33017 lies in how the public flow build endpoint handles its optional data parameter. When an attacker supplies this parameter, the endpoint uses the attacker-controlled flow data instead of retrieving stored flow data from the database. This flow data can contain arbitrary Python code embedded within node definitions. The server processes this data through Langflow’s graph construction pipeline — traversing create_graph() → build_graph_from_data() → instantiate_class() → prepare_global_scope() — where the final function evaluates Python assignments via dynamic code execution with no sandboxing, input validation, or code restriction [6].

The attack requires no authentication because the endpoint is designed to serve unauthenticated users accessing public flows. The default Langflow configuration ships with AUTO_LOGIN=true, meaning authentication is disabled globally unless explicitly configured otherwise. Exploitation requires a single crafted HTTP POST request with a JSON payload containing malicious Python code in the flow’s node definitions. An attacker can also create their own public flow to obtain a valid flow_id, eliminating any dependency on pre-existing target data [6].

The technical execution path makes this vulnerability particularly accessible: it can be triggered from a standard HTTP client with no specialized tooling, and the malicious payload fits within a compact JSON structure. RAXE Labs independently confirmed that compensating controls — specifically, blocking unauthenticated access to the build endpoint and disabling public flows — represent the only reliable mitigations for unpatched deployments [6].

Patch Complications

The remediation picture was complicated by incomplete patching. Langflow’s initial communications suggested a fix was included in version 1.8.2, and some third-party sources reported it as patched. JFrog Security Research investigated and found that version 1.8.2 remained fully exploitable in both PyPI and Docker environments. Upon examining version 1.8.2’s commits, the researchers were unable to identify the patch that was reportedly applied, suggesting the release notes did not accurately reflect the actual code changes [3].

JFrog identified Langflow 1.9.0 as the first version containing an effective remediation, and recommended that organizations using versions prior to 1.9.0 treat their deployments as unpatched regardless of minor version claims. This finding has direct operational significance: organizations that believed they had addressed the vulnerability by upgrading to 1.8.2 may have remained exposed.

Exploitation Timeline and Observed Techniques

The Sysdig Threat Research Team documented the exploitation sequence with precision. The advisory was published at 20:05 UTC on March 17, 2026. The first exploitation attempt was recorded at 16:04 UTC on March 18 — approximately 20 hours later — with no public proof-of-concept repository available at that point [1]. With no public proof-of-concept available, attackers appear to have constructed working exploits from the advisory text or through independent analysis of the disclosed endpoint behavior.

Exploitation proceeded in distinct phases. An initial wave of automated scanning, beginning around hour 20 post-disclosure, used templated payloads executing identity commands and exfiltrating results via base64 encoding to out-of-band callback servers. This phase involved four unique source IPs using identical nuclei scanner payloads, consistent with automated mass-exploitation tooling. By hour 21, more targeted operators using custom Python scripts conducted methodical reconnaissance — including directory listing, targeted access to credential files, and system fingerprinting — before staging secondary payloads. The most advanced operators, active from approximately hour 24 onward, performed systematic credential harvesting through environment variable dumps and targeted searches for .db and .env files [1].

Sysdig’s research also contextualized this timeline within a broader industry pattern: 44% of exploited vulnerabilities are weaponized within 24 hours of disclosure, reflecting a documented pattern of rapid weaponization that leaves defenders minimal response time [1].

Enterprise-Specific Risk Profile

The consequences of a Langflow compromise extend substantially beyond the compromised host. Enterprise AI development environments frequently aggregate credentials for multiple external services in a single platform for development convenience. Attackers who exfiltrated environment variables from Langflow instances captured API keys for OpenAI, Anthropic, and AWS; database connection strings; cloud provider credentials; and application secrets — providing authenticated access to the organization’s AI infrastructure, data stores, and potentially its software supply chain [1].

Approximately 7,000 Langflow instances have been identified as internet-accessible, with the majority located in North America [7]. This exposure profile reflects a common pattern in developer tooling: internal-facing platforms are deployed without the same network access controls applied to customer-facing production systems, often because they are expected to serve teams collaborating across locations or cloud environments.

A Monero cryptocurrency mining campaign documented by Trend Micro, active from late March through mid-April 2026, demonstrated continued attacker interest even as a patch was available [8]. The persistence of this campaign suggests a meaningful portion of the exposed instance population had not applied the available remediation.

Compounding Vulnerability: CVE-2026-5027

Separately from CVE-2026-33017, Langflow was also found to contain CVE-2026-5027, a high-severity path traversal vulnerability in the file upload functionality. The POST /api/v2/files endpoint fails to sanitize the filename parameter from multipart form data, allowing attackers to write files to arbitrary filesystem locations [9]. The co-presence of CVE-2026-33017 and CVE-2026-5027 suggests that Langflow’s attack surface warrants a systematic security review. Organizations should not assume that addressing the disclosed CVEs fully resolves their exposure.

Recommendations

Immediate Actions

Organizations running any version of Langflow prior to 1.9.0 should treat the deployment as actively exploitable and prioritize upgrading to version 1.9.0 or later as the only verified remediation for CVE-2026-33017 [3]. Given the JFrog finding that version 1.8.2 was ineffectively patched, version strings alone are not a reliable indicator of protection. Teams should verify they are running the 1.9.0 release from official channels (PyPI or the official Docker image) and not an intermediate or unofficial build.

Concurrently with any patching effort, organizations should rotate all credentials that were accessible to any Langflow instance that may have been exposed. This includes API keys for AI services, cloud provider credentials, database connection strings, and any secrets stored in environment variables or .env files accessible on the host system. Rotation should proceed regardless of whether exploitation is confirmed, because the absence of observed indicators does not exclude credential exfiltration in earlier phases of the attack lifecycle.

For federal agencies, CISA’s BOD 22-01 compliance obligations applied an April 8, 2026 remediation deadline; any agency that has not yet addressed this vulnerability is outside that window and should escalate remediation accordingly [2].

Short-Term Mitigations

Until systems are patched, the most effective compensating control is restricting network access to Langflow instances. The vulnerable endpoint should not be reachable from untrusted networks. Organizations should place Langflow deployments behind a VPN or firewall that limits access to authenticated internal users, and disable internet exposure entirely if the platform’s workflow does not require it. Disabling the public flow feature at the application level also eliminates the unauthenticated endpoint as an attack surface for the specific CVE-2026-33017 mechanism.

Security teams should conduct a retrospective review of Langflow access logs for the period from March 17, 2026 onward. The exploitation indicators documented by Sysdig — base64-encoded command outputs exfiltrated to external callback servers, directory traversal patterns in HTTP request paths, and unusual POST requests to the /api/v1/build_public_tmp/ endpoint — provide a basis for detection [1]. Where log retention predates the vulnerability disclosure, teams should assess whether post-exploitation persistence mechanisms (scheduled tasks, modified files, reverse shell infrastructure) may still be present.

Strategic Considerations

The Langflow incident illustrates a recurring pattern: AI development infrastructure may be held to lower security standards than production systems, despite carrying equivalent or greater credential and data sensitivity. Organizations should evaluate whether this gap exists in their own environments, and apply a production-equivalent security posture to their development tooling. This includes placing AI development platforms within the scope of vulnerability management programs, requiring that public-facing developer tools pass the same security review as production services, and enforcing secret management practices — such as short-lived credentials and vault-based injection — that limit the blast radius of a host compromise.

The AI development supply chain deserves explicit attention. An attacker with an OpenAI or Anthropic API key gained through a Langflow compromise can impersonate the affected organization to those services, submit queries that consume organizational budget or data, or potentially manipulate model interactions. Organizations should review their AI service provider agreements for notification obligations in the event of credential compromise and evaluate whether their current monitoring would detect anomalous API usage patterns.

Enterprises deploying AI agent frameworks should evaluate whether open-source development tools undergo appropriate security review before adoption. The pattern of rapid exploitation observed with CVE-2026-33017 — a critical unauthenticated RCE in a widely adopted platform, exploited before public PoC availability — is well-established across the vulnerability landscape and should be expected to recur against AI development tooling. A proactive procurement posture that includes security review of AI development tooling, and a monitoring posture that detects anomalous behavior in AI infrastructure, should reduce organizational exposure to the next such disclosure.

CSA Resource Alignment

The security issues raised by CVE-2026-33017 map directly to several Cloud Security Alliance frameworks and research initiatives.

The MAESTRO threat modeling framework for agentic AI systems addresses the attack surface at Langflow’s level of the stack. MAESTRO’s Layer 3 (Agent Frameworks and Orchestration) explicitly covers orchestration platforms that execute code and chain tool calls — the same architectural layer where Langflow operates and where CVE-2026-33017 is exploitable. Layer 4 (Deployment and Infrastructure) also applies: the cloud and infrastructure credentials that Langflow aggregates become available to an attacker upon host compromise, making the deployment environment itself a target. Organizations threat-modeling their AI development environments should treat Langflow, and any comparable orchestration platform, as a high-priority asset at these layers. CSA’s MAESTRO framework is available at cloudsecurityalliance.org [10].

The AI Controls Matrix (AICM) provides control guidance directly applicable to this incident. AICM’s supply chain security domain addresses the risks introduced when AI development platforms aggregate third-party service credentials, and its runtime security controls speak to the need for isolation and sandboxing in code-executing AI frameworks. The AICM’s shared responsibility model is also relevant: organizations that deploy Langflow as an orchestrated service provider assume security responsibility for the platform’s configuration and network exposure [11].

CSA’s Zero Trust guidance applies to the network access patterns that made exploitation at scale possible. Approximately 7,000 internet-exposed Langflow instances reflect deployment practices inconsistent with Zero Trust principles — specifically, the principle that internal tools should not be reachable from the public internet without explicit access controls [12]. The default Langflow configuration’s AUTO_LOGIN=true setting is similarly inconsistent with Zero Trust’s identity verification requirements.

Finally, CSA’s AI Organizational Responsibilities guidance addresses the governance dimension: security teams need visibility into which AI development tools are deployed in their environments, whether those tools are within the scope of patch management, and how credential exposure in development infrastructure is scoped, detected, and responded to. The persistence of unpatched Langflow instances through April 2026 suggests many organizations lack this visibility.

References

[1] Sysdig Threat Research Team. “CVE-2026-33017: How Attackers Compromised Langflow AI Pipelines in 20 Hours.” Sysdig, March 2026.

[2] CISA. “CISA Adds One Known Exploited Vulnerability to Catalog.” CISA, March 25, 2026.

[3] JFrog Security Research. “Langflow CVE-2026-33017: Latest ‘Fixed’ Version Is Still Exploitable.” JFrog, March 2026.

[4] The Hacker News. “Critical Langflow Flaw CVE-2026-33017 Triggers Attacks Within 20 Hours of Disclosure.” The Hacker News, March 2026.

[5] Langflow AI. “Unauthenticated Remote Code Execution in Langflow via Public Flow Build Endpoint.” GitHub Security Advisory GHSA-vwmf-pq79-vjvx, March 2026.

[6] RAXE Labs. “RAXE-2026-043: Langflow Unauthenticated Code Injection RCE via Public Flow Build Endpoint (CVE-2026-33017).” RAXE Labs, March 2026.

[7] Bleeping Computer. “Path Traversal Flaw in AI Dev Platform Langflow Exploited in Attacks.” Bleeping Computer, 2026.

[8] The Hacker News. “Langflow RCE Exploited to Deploy Monero Miner on Exposed AI App Endpoints.” The Hacker News, June 2026.

[9] Hexnode. “Langflow CVE-2026-5027 Exploited Against AI Development Platforms.” Hexnode, 2026.

[10] Cloud Security Alliance. “Agentic AI Threat Modeling Framework: MAESTRO.” CSA, February 2025.

[11] Cloud Security Alliance. “AI Controls Matrix v1.1.” CSA, 2025.

[12] Cloud Security Alliance. “Zero Trust Guidance for Critical Infrastructure.” CSA, October 2024.