All posts
Unproven Execution

Flowise CSV Agent RCE: Unproven Execution Encore

CVE-2026-41264 turns Flowise's CSV Agent into a remote Python interpreter — the same unproven_execution pattern Langflow shipped six weeks ago

Securityv0 Intelligence Team OWASP: ASI05 sv0 finding: unproven_execution
flowise csv-agent prompt-injection unproven-execution asi05 ai-workflow

The Incident

On April 15, 2026, FlowiseAI published GHSA-3hjv-c53m-58jj, assigned CVE-2026-41264, disclosing an unauthenticated remote code execution flaw in the CSV Agent node of Flowise — a popular open-source visual builder for LLM workflows. The vulnerability lives in the run() method of the CSV_Agents class shipped in flowise and flowise-components ≤ 3.0.13 on npm, with a fix released in 3.1.0. The advisory was reported through Trend Micro’s Zero Day Initiative under tracking ID ZDI-CAN-29411. Its published CVSS v4.0 vector is AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H.

The mechanic is simple and depressingly familiar. A chatflow operator wires a CSV Agent node into the graph so an LLM can answer questions about an uploaded CSV. The agent’s run() method takes the LLM’s free-text response, extracts a Python script, and evaluates it server-side in a non-sandboxed context — gated only by a regex denylist of forbidden imports. An attacker who can send a prompt to the chatflow (no authentication required in Flowise’s default exposed configuration) coerces the LLM into emitting a Python script that aliases dangerous modules past the denylist (e.g., import pandas as np, os as pandas) and runs arbitrary OS commands under the Flowise process. An authenticated attacker can skip the LLM entirely by pointing the chatflow at an attacker-controlled “OpenAI-compatible” endpoint that returns a chosen Python script. CVE-2026-41264 explicitly bypasses the regex-denylist mitigation tracked as CVE-2026-41137 against the same component. There is no public report of in-the-wild exploitation tied to CVE-2026-41264 as of publication; the active-exploitation campaign currently hammering Flowise concerns the unrelated CustomMCP RCE (CVE-2025-59528), and the two should not be conflated.

MITRE ATT&CK coverage: T1059.006 Command and Scripting Interpreter: Python, T1190 Exploit Public-Facing Application, T1068 Exploitation for Privilege Escalation.

The Authority Path That Failed

The exercising identity is the Flowise server process running a chatflow. The deploying operator’s intent is bounded: read a CSV, summarize it, return the answer. The held scope is unbounded — the CSV Agent silently wires the LLM’s free-text output into an unsandboxed Python evaluator that runs with the full privileges of the Flowise process: cloud credentials, OpenAI/Anthropic API keys, vector-store credentials, container filesystem access, internal-network reachability. Nothing in the chatflow definition declares “this node may execute arbitrary Python.” The framework declares it for you.

The trust anchor that failed first is the assumption that LLM-emitted code can be filtered safely with a regex denylist. CVE-2026-41137 already demonstrated that assumption breaking once for this same component; CVE-2026-41264 demonstrates it breaking a second time, this time via import-aliasing. Pattern-matching cannot keep up with the search space of legal Python that imports os. The gap between the operator’s authorized scope (“answer questions about a CSV”) and the agent’s exercised scope (“execute attacker-supplied OS commands on the host”) was discoverable pre-incident — not by SAST, but by inventorying which agent nodes attach a code-execution tool to LLM output, and asking how that tool is sandboxed.

SecurityV0 Perspective

This is unproven_execution, OWASP ASI05 — the same finding SecurityV0 published against Langflow’s CSV Agent + Python REPL combination on March 9, 2026. Two leading visual AI-workflow builders, six weeks apart, shipping the same architectural anti-pattern: an LLM-output-to-code-eval edge whose only guardrail is a denylist. That promotes the finding from “one framework’s bug” to “class-of-vulnerability across the AI-workflow-builder ecosystem,” and it changes the defender question from “is Flowise patched?” to “which of my chatflows wire LLM output into a code interpreter, and what does that interpreter have access to?”

The evidence pack SecurityV0 would generate against a Flowise deployment ties together (1) the chatflow node graph — every CSV Agent, Python tool, JS tool, code-interpreter, or shell-tool node, in any chatflow, any environment; (2) the host NHIs reachable from the Flowise process — cloud SDK credentials, registry tokens, vector-store keys, secrets-manager scopes; and (3) the actual installed version of flowise and flowise-components, against the ≤ 3.0.13 affected range. Pre-incident, that pack answers: “if the LLM in this chatflow returns arbitrary Python tomorrow, what does it own?” Post-incident, it answers the forensic question: “which chatflows could have served as the entry point, and which NHIs are now suspect?”

What To Do

  • Upgrade flowise and flowise-components to 3.1.0 or newer immediately. Pin the version in your image build and CI; do not rely on latest. Re-test any chatflow that uses the CSV Agent node against your sample inputs after upgrade. The same component has now had at least two regex-denylist bypasses (CVE-2026-41137, CVE-2026-41264), so plan for a third.
  • Treat every code-execution-capable agent node as a remote interpreter. CSV Agent, Python tool, JavaScript tool, shell tool, code-interpreter — across Flowise, Langflow, LangChain, Dify, and equivalents — can attach an evaluator to LLM output. If you can’t justify “this chatflow needs to run arbitrary code,” remove the node. If you must keep it, run the chatflow in a process isolate (gVisor, Firecracker microVM, or at minimum a per-chatflow container with no production credentials and no internal-network reachability).
  • Block unauthenticated access to chatflows by default. Flowise’s default deployment exposes the chatflow API publicly; CVE-2026-41264 is reachable without auth in that posture. Front Flowise with an authenticated reverse proxy or Flowise’s API-key auth, scope keys per chatflow, and disable any chatflow that does not require auth before its first public exposure.
  • Inventory the NHIs each chatflow can reach. For every chatflow, enumerate which cloud credentials, API keys, vector stores, and internal services its host process can touch. A code-execution-capable node’s blast radius is exactly that set. Rotate any credential that lived on a Flowise host running ≤ 3.0.13, even without confirmed exploitation — denylist-bypass classes are notoriously under-detected.
  • Restrict model-endpoint URLs at the proxy layer. CVE-2026-41264’s authenticated path lets a user point a chatflow at any URL that speaks the OpenAI chat-completions wire format and have the resulting “completion” executed as Python. Allow-list the model endpoints at the network egress layer, not in the application config — application-config restrictions are bypassable by anyone who can edit a chatflow.

Sources

All posts