Langflow CVE-2026-10134: Critical RCE in AI Flow Builder

A newly disclosed flaw in Langflow, the popular open-source visual builder for AI workflows and agents, lets an unauthenticated attacker run arbitrary code on the server. Tracked as CVE-2026-10134 and carrying the maximum CVSS score of 10.0, the vulnerability affects Langflow OSS versions 1.0.0 through 1.9.3 and is fixed in version 1.10.0. It is the latest in a run of critical remote-code-execution bugs in the same tool — a pattern that says as much about how AI orchestration platforms are built as it does about any single line of code.

What Langflow is, and why the bug matters

Langflow is a drag-and-drop environment for wiring up AI applications — chaining language models, tools, retrieval steps, and custom logic into runnable “flows.” It is widely self-hosted by developers and companies prototyping agentic systems, which means many deployments sit on internal networks or, riskily, on the public internet with a web UI exposed.

That exposure is the problem. A flow builder’s entire purpose is to execute user-defined logic, and Langflow includes components that run arbitrary Python by design. When the boundary between “code the operator wrote” and “code an outsider can submit” fails, the result is exactly what CVE-2026-10134 delivers: remote code execution as the Langflow process, with access to whatever secrets, databases, and network position that process holds.

How the exploit works

The vulnerability lives in Langflow’s PythonCodeStructuredTool component, which executes attacker-influenced Python through Python’s exec() function at flow-build time. In the vulnerable code path, a template field carries the tool’s code straight into exec(self.tool_code, globals(), local_namespace) — and that field is attacker-controllable.

There are two routes to the sink, and the second is the dangerous one:

• Authenticated path. A POST to /api/v1/build/{flow_id}/flow with a valid session token triggers the build and, with it, the exec() call. This requires credentials.
• Unauthenticated path. Once a flow is marked PUBLIC — a state an attacker can set via PATCH /api/v1/flows/{flow_id} with {"access_type": "PUBLIC"} — the endpoint /api/v1/build_public_tmp/{flow_id}/flow accepts builds with no Authorization header at all, running exec() on the server for any anonymous caller.

That second path is why the CVSS vector reads AV:N/AC:L/PR:N/UI:N — network-accessible, low-complexity, no privileges required, no user interaction, with a scope change and complete loss of confidentiality, integrity, and availability. It is the worst-case combination: a fully unauthenticated attacker reaching code execution over the network with a single crafted request.

What an attacker gets

Code execution as the Langflow process is not the end state — it is the foothold. From there, the concrete impact reported for this class of flaw includes:

• Reading every secret the process can see — API keys for the language models and third-party services wired into flows, database credentials, and cloud tokens held in the environment.
• Reading and altering flows, conversations, and messages in the backing database, letting an attacker quietly rewrite the logic of an AI application or exfiltrate its data.
• Using the server as a pivot into the rest of the internal network, since Langflow instances frequently run close to the model endpoints and data stores they orchestrate.

For teams building agents, that last point compounds the risk. An orchestration server typically holds the keys to everything downstream — the model APIs, the tool integrations, the vector stores. Compromising it is often equivalent to compromising the whole application. Understanding why hashing is not encryption or how tokens are scoped is little help when the plaintext secrets are simply readable from process memory and environment.

A repeating pattern

CVE-2026-10134 does not stand alone. Langflow has absorbed a string of critical RCE findings — including an earlier unauthenticated flaw that was exploited in the wild after a proof-of-concept circulated, and at least one case where a version marketed as “fixed” was found still exploitable by researchers. The recurring theme is the same: endpoints that execute user-supplied code, guarded by authentication logic that turns out to be bypassable.

This is the structural tax of the AI-tooling boom. Flow builders, agent frameworks, and no-code AI platforms are shipping fast, and their core value proposition — “let users run arbitrary logic against powerful models” — is inherently a dangerous surface. The same dynamic showed up in agentic ransomware like JadePuffer and in poisoned proof-of-concept code planted on GitHub: as AI infrastructure proliferates, it becomes a target class of its own, and the plumbing is often less hardened than the models it serves.

How to remediate

The fix is straightforward; the urgency is not optional given the 10.0 rating and the unauthenticated path:

1. Upgrade to Langflow OSS 1.10.0 or later immediately. This is the vendor-recommended remediation and the only complete fix.
2. Get exposed instances off the public internet. If a Langflow UI or API is reachable from the open web, restrict it now — behind a VPN, an authenticating reverse proxy, or network policy — regardless of version.
3. Audit for PUBLIC flows. Review whether any flows have access_type set to PUBLIC, and treat an unexplained public flow as a potential indicator of compromise.
4. Rotate every secret the instance could reach. Because the vulnerability exposes process secrets directly, assume model API keys, database credentials, and service tokens on any internet-facing, unpatched instance may already be compromised, and rotate them.
5. Hunt for prior compromise. Look for unexpected outbound connections, new or modified flows, and anomalous exec()-driven activity in logs. Exploitation of this bug class has preceded disclosure before.

Layered controls help contain the blast radius even when a component fails. Network segmentation and zero-trust principles limit how far an attacker can move from a compromised orchestration server, and keeping AI tooling off the public internet remains the single highest-value control for this category of software.

What it means

CVE-2026-10134 is a clean illustration of where the security frontier is moving. The vulnerability itself is a familiar exec()-to-RCE bug, but its context is new: it sits inside the connective tissue of modern AI applications, where a single compromised builder can surrender the keys to every model and data store it touches.

Who’s exposed. Anyone self-hosting Langflow OSS below 1.10.0 — disproportionately the fast-moving teams prototyping agents, where a demo instance quietly left on a public IP is exactly the failure mode this bug rewards. Managed and properly network-isolated deployments are far less exposed, which reinforces the case for never putting AI orchestration tools directly on the open web.

The lesson to internalize. The AI stack is only as secure as its least-hardened component, and right now that is rarely the model — it is the orchestration layer around it, built quickly and holding all the secrets. Treat every agent framework and flow builder as a high-value RCE target, patch it on the vendor’s timeline rather than your own, and assume that “runs user code” means “runs an attacker’s code” until proven otherwise.

What to watch next. Expect broad internet scanning for exposed Langflow endpoints now that the flaw is public, and watch for the same weaponization curve that followed earlier Langflow bugs — a working exploit, then opportunistic mass exploitation of the instances that never upgraded. The number that will matter is how many unpatched, internet-facing Langflow servers remain online in the weeks ahead.