Langflow unauthenticated RCE - CVE-2026-48519

CVE-2026-48519 is an unauthenticated remote code execution flaw in Langflow's Shareable Playground, rated Critical and classified as CWE-94 (improper control of code generation). Langflow is an open-source low-code visual builder for LLM and AI-agent workflows, and its Shareable Playground lets unauthenticated users run a workflow through a public link. The flaw affects Langflow through 1.9.1 and is fixed in 1.9.2. This advisory covers what the bug exposes, why a flow builder is an agentic-endpoint problem, and how Anomity surfaces and governs the agents and artifacts around it.

What happened

Langflow builds and runs agent workflows from a visual graph. The Shareable Playground feature exists so that a flow can be run through a public link without the caller signing in, which is convenient for demos and handoffs and is exactly where the trust boundary breaks.

The public build endpoint /api/v1/build_public_tmp accepts a JSON body that describes the flow to construct. Within that body, the field data.nodes[X].data.node.template.code.value carries Python source, and in the affected versions that value is accepted without validation. When the shared flow is built, Langflow instantiates and executes that code during graph building. Because the endpoint is reachable without authentication, an attacker who can reach a vulnerable instance submits a crafted flow and the server runs their Python. The code path that builds the flow is itself the execution primitive, which is what makes this unauthenticated remote code execution rather than a lesser injection.

The fix landed in Langflow 1.9.2. Every version through 1.9.1 is affected, so the practical answer is to upgrade and, until then, to keep the Shareable Playground and the public build path off any network an untrusted caller can reach.

Why this is an agentic-endpoint risk

Langflow is not a passive service. It is a low-code AI-agent and flow builder that ships and runs agent workflows, so a vulnerable instance is a place where AI artifacts are authored, stored, and executed. When the builder itself runs attacker-supplied Python, everything that instance can reach - the agents it defines, the credentials those flows use, the MCP servers and tools they call - is now downstream of an unauthenticated request.

That reachability is the risk. A flow builder tends to appear outside standard change control: a developer stands one up to prototype an agent, exposes the Shareable Playground for a demo, and the instance keeps running. Network and EDR controls see the process and its connections, but cannot tell you which endpoints run an affected Langflow build, which agents were authored on it, or whether the public build path is reachable without authentication. That is the artifact-layer blind spot, and you can't govern what you can't see.

This is the same pattern we track across the agent-framework cluster, including the sibling cases in Flowise Airtable agent code injection - CVE-2026-41265 and LangChain unsafe deserialization - CVE-2026-44843. A builder that executes code from a request is one node in a graph of AI artifacts, which is why the same discipline applies to the tools that drive it. Fleet-wide inventory of every AI artifact is the precondition for scoping an RCE like this one, and the coding agents and CLIs that reach these builders carry their own exposure, covered in the pillar on securing AI coding agents and CLIs.

How Anomity surfaces and governs it

Anomity inventories eight AI artifact types on every managed endpoint: AI agents, MCP servers, extensions, skills, plugins, secrets, hooks, and CLIs. For CVE-2026-48519 that means a Langflow install and its version are catalogued alongside the agents and CLIs that drive it, so you can answer "which endpoints run an affected Langflow build, and what talks to it" from the fleet inventory instead of guessing across machines that were never registered with change control.

On agents that expose a hook, such as Claude Code PreToolUse, Anomity returns allow, deny, or log on each tool call before it runs. That is the enforcement point in runtime governance: a tool call that stands up or reaches an unapproved builder, or that drives a flow through a public build path, can be denied or logged in line rather than discovered after the server has already executed attacker code. Anomity collects metadata only and redacts secrets on the endpoint, so credentials that a compromised flow could reach never pass through Anomity.

Every decision is written to a queryable 90-day audit trail. After a disclosure like this, that trail is what lets responders scope the event: which agents reached a Langflow instance, when, and what they invoked. Anomity routes those decisions to SIEM, Slack, email, or Jira so the right team sees them in the tool they already use. The result is the timeline and the enforcement record described under outcomes.

Anomity complements your existing Network, EDR, DLP, and GRC controls rather than replacing them, adding the agentic-endpoint layer those tools cannot see, and it is SOC 2 Type II. See how it works and how Anomity compares for where it fits.

What to check across your fleet

• Identify every endpoint and service running Langflow and record the exact version; treat anything through 1.9.1 as affected and upgrade to 1.9.2 or later.
• Confirm the running version rather than the intended one, since low-code builders are often stood up outside standard change control.
• Restrict network reachability so the Shareable Playground and the /api/v1/build_public_tmp endpoint are not accessible to untrusted callers without authentication.
• Disable public flow sharing on any instance that does not need it, and require authentication in front of the builder's API.
• Review logs for requests to /api/v1/build_public_tmp and for unexpected Python execution or child processes spawned by the Langflow process.
• Enumerate the agents, flows, and credentials authored on each Langflow instance so you know what a code-execution event would expose.
• Use a fleet-wide AI artifact inventory to map which AI agents and CLIs can reach or drive a Langflow instance.
• Confirm hook-based allow/deny/log enforcement is active on agents that reach these builders, so a call to an unapproved or public build path can be blocked before it runs.

CVE-2026-48519 turns one public build request into unauthenticated code execution on the server that authors your agent workflows, which is exactly why the AI artifact layer needs its own inventory and enforcement. For the full cluster context, see the pillar on securing AI agent frameworks. To see Anomity inventory your agents, govern tool calls at the hook, and keep a 90-day audit trail, request early access.