Critical Langflow Vulnerability Exposes AI Workflows and API Keys to Active Exploitation

A critical Langflow vulnerability tracked as CVE-2026-33017 is being actively exploited after attackers found a way to turn a public AI workflow-building endpoint into unauthenticated remote code execution. The flaw, now listed in the federal Known Exploited Vulnerabilities catalog, puts exposed Langflow deployments at risk of leaking internal workflows, API keys, model integrations, database credentials and developer infrastructure access.

Langflow is an open-source platform used to build and deploy AI agents, workflows and retrieval-augmented generation pipelines. Its appeal is also what makes the bug dangerous: these systems often sit between large language models, vector databases, cloud services, internal APIs and application data stores. A compromise of the workflow builder can therefore become a compromise of the surrounding AI development environment.

The vulnerability affects the public flow build endpoint:

POST /api/v1/build_public_tmp/{flow_id}/flow

The endpoint was designed to allow public Langflow flows to be built without normal authentication. The security failure came from allowing a request to include attacker-controlled flow data. Because Langflow flows can contain custom Python components, malicious node definitions could reach unsandboxed Python execution through exec(), giving an attacker code execution on the server.

Versions up to and including 1.8.2 are affected. The issue is fixed in Langflow 1.9.0 and later. The flaw is rated critical, with a vendor CVSS v4 score of 9.3 and a separate CVSS 3.1 score of 9.8 in vulnerability tracking data.

The attack is not a generic web-app bug buried in an obscure feature. It abuses the build path of an AI workflow builder. In practical terms, an attacker who reaches a vulnerable internet-facing instance and obtains or creates a usable public flow can submit malicious workflow data and make the server execute Python code before the intended AI workflow even runs.

That makes this an AI security problem as much as a software vulnerability. Langflow deployments commonly hold or can reach high-value secrets: model-provider API keys, database connection strings, cloud tokens, internal flow definitions, prompt chains, vector-store access and credentials stored in .env files or environment variables. A successful attacker may not stop at proving code execution; the next steps are often reconnaissance, secret discovery and lateral movement.

Early exploitation followed that pattern. Security researchers observed attempts roughly 20 hours after the vulnerability advisory became public. Initial activity included automated scanning and command execution to confirm access. Later activity moved into directory listing, system file reads, environment-variable dumping, searches for .env and database files, outbound callbacks and attempts to stage follow-on payloads.

The speed matters. Attackers appeared able to weaponize the advisory details quickly, without needing a widely distributed public exploit repository first. That shortens the defensive window for organizations running AI development tools outside hardened production environments, particularly demo systems, shared prototypes and data-science infrastructure that may be internet-facing but not covered by the same patching discipline as core enterprise services.

B
Attacker-controlled flow data
Malicious Python in node definition
Unsandboxed exec
Remote code execution
Secrets, workflows and infrastructure exposed
Exposed Langflow instance] --> B[Public flow build endpoint

Not every Langflow deployment is automatically exploitable. The highest-risk cases are vulnerable versions exposed to the internet where public flows are enabled or where permissive configuration makes it possible for an unauthenticated user to create or access public flows. The attack path may require knowledge of a public flow UUID, which can be exposed through shared links or URLs. In some configurations, an arbitrary client_id cookie may be enough to reach the vulnerable path.

Still, the federal KEV listing changes the urgency. CVE-2026-33017 is no longer a theoretical code defect. It is an exploited AI development tool vulnerability that defenders should prioritize ahead of lower-risk backlog items, especially if Langflow is connected to production data sources, cloud accounts or model-provider billing accounts.

The primary fix is straightforward: upgrade to Langflow 1.9.0 or later. The patch removes the unsafe acceptance of attacker-supplied flow data in the public build path and forces public flows to use stored flow definitions rather than request-supplied executable content.

For teams that cannot patch immediately, containment should focus on reducing exposure. Administrators should restrict or disable access to build_public_tmp, disable or tightly control public-flow building, place Langflow behind authentication or VPN access, and remove direct internet exposure for development and demo instances. A reverse proxy or firewall rule can reduce risk while upgrade testing is completed, but it should not be treated as a permanent substitute for patching.

Organizations that had vulnerable Langflow instances exposed before patching should treat the incident as a possible credential-exposure event. That means rotating model-provider API keys, database passwords, cloud tokens and secrets stored in environment variables or .env files. Logs should be reviewed for requests to build_public_tmp, suspicious client_id values, unexpected data fields, shell command execution, reads of .env or database files, and unusual outbound DNS or HTTP traffic.

The broader lesson is that AI workflow platforms are becoming privileged attack surfaces. They are often easy to deploy, useful for rapid prototyping and deeply connected to sensitive systems. That combination is attractive to developers — and to attackers.

CVE-2026-33017 shows how a single code injection flaw in an AI builder can expose far more than one application. In modern AI environments, the workflow layer may hold the keys to models, data, prompts, automation logic and infrastructure. Securing that layer now requires the same urgency traditionally reserved for public-facing identity systems, CI/CD platforms and cloud control planes.