Flowise's CVE-2026-41264 Turns an LLM-Written `import` Statement Into Unauthenticated RCE — and Breaks the Regex-Gated Sandbox

Flowise’s CSV Agent evaluated LLM-generated Python through a regex import filter intended to confine execution to pandas and numpy. The flaw: the filter assumed a human attacker typing an import statement, but the LLM generates the code — and a prompt-injected query tricking the model into aliasing os as pandas bypassed the gate entirely, yielding unauthenticated remote code execution.

The Vulnerability: How a Regex Import Filter Became RCE

FlowiseAI disclosed CVE-2026-41264 in mid-April 2026, affecting flowise and flowise-components through version 3.0.13¹. The vulnerability carries a CVSS v3.1 score of 9.8¹. At its core is the CSV Agent’s run() method, which takes a user’s natural-language query about a CSV file, passes it to an LLM, and executes the resulting Python code server-side in a Pyodide environment².

The defense was a regex — /\bimport\s+(?!pandas|numpy\b)/g — designed to block any import except pandas and numpy. The advisory describes the execution context as “non-sandboxed”², meaning a successful bypass gives the attacker full OS access, not merely a WASM escape.

Two vectors exist. The first is unauthenticated: an attacker sends a crafted prompt to /api/v1/prediction/<chat_id> and tricks the LLM into emitting malicious Python². The second requires authentication: an attacker configures a custom LLM server that returns attacker-controlled Python directly². In both cases, the code reaches the same evaluator.

The Bypass: import pandas as np, os as pandas

The regex blocked imports that did not match pandas or numpy. It did not block aliasing. An attacker could craft a prompt that caused the LLM to generate:

import pandas as np, os as pandas
pandas.system("...")

Here os is imported under the name pandas, which satisfies the negative lookahead. The code then calls pandas.system(...) — which is os.system(...) — giving shell access. The vulnerability was discovered by Dre Cura and Nicholas Zubrisky of TrendAI Research and disclosed through Trend Micro’s Zero Day Initiative as ZDI-CAN-29411².

Why Pyodide Is Not the Sandbox Here

Pyodide runs Python in WebAssembly, which provides process-level isolation from the host OS. But isolation is not the same as sanitization. The Flowise advisory explicitly calls the execution environment “non-sandboxed”², and for good reason: the CSV Agent runs the generated Python through eval() or equivalent execution paths inside a Node.js process that has already loaded the Pyodide runtime with host-level permissions. WASM does not help when the Python code being evaluated can call os.system() against a filesystem the host can see.

The Broader Pattern: When the LLM Is the Attacker’s Typist

The critical assumption behind the original regex was that the attacker writes the import line. In a traditional code-injection vulnerability — SQLi, command injection, XSS — that assumption holds: the attacker supplies a string that the application executes. Here, the attacker supplies a prompt, and the LLM translates that prompt into a program. The import statement is syntactically valid, semantically reasonable, and produced by a model trained to be helpful. The regex never had a chance because it was guarding against the wrong threat model.

This shifts the vulnerable surface from “can the attacker inject code?” to “can the attacker inject a prompt that produces code the sanitizer cannot recognize?” Every framework that lets an LLM emit executable Python against a lexical filter — Langflow, Dify, n8n AI nodes, and others — faces the same structural risk. There is no evidence yet that these frameworks share the exact same bypass, but the architectural analogy is direct: if your sanitizer assumes it is reading attacker-written text, it will miss LLM-rewritten text.

What Other Frameworks Should Audit Now

Frameworks with LLM-to-code pipelines should audit three specific things:

1. Who generates the executable text? If the LLM writes it, a regex that blocks human-authored attack strings is insufficient.
2. Is the execution environment actually sandboxed? Running inside Pyodide, WASM, or a Docker container is not the same as denying filesystem, network, and subprocess access. Check what the Python code can reach, not just what the runtime is compiled to.
3. Are allowlists enforced at the AST or namespace level? The Flowise fix moved from a regex to blocking all imports with /\bimport\b/g because pandas and numpy are pre-imported by the executor³. Namespace-level enforcement — only exposing specific modules in the execution globals — is stronger than text-level enforcement.

Patch Timeline and Mitigation

Flowise merged the fix on March 5, 2026, in PR #5879³. The change replaced the permissive regex with /\bimport\b/g, which blocks all import statements since pandas and numpy are already available in the execution context. The same PR added 61 unit tests covering import bypasses³. The advisory was published in mid-April 2026, and the ZDI disclosure (ZDI-CAN-29411) followed shortly after¹².

Users on flowise-components ≤3.0.13 should upgrade to 3.1.0 or later. If patching is not immediately possible, restricting network access to the prediction endpoint and disabling the CSV Agent entirely are the only reliable mitigations. The authenticated vector — custom LLM servers — means that even prompt-hardening cannot fully eliminate risk if untrusted model endpoints are permitted.

Frequently Asked Questions

Is CVE-2026-41264 listed in NVD yet?

As of the advisory’s publication, the CVE remained in RESERVED status in the National Vulnerability Database. Vulnerability scanners that pull exclusively from NVD — rather than GitHub Advisory Database or ZDI — will not automatically flag affected Flowise installations.

Was the regex allowlist the first attempt to sanitize CSV Agent code?

No. PR #5701 introduced the original regex-based sanitizer for Pyodide execution, using the negative lookahead pattern. PR #5879 later replaced it with a blanket import block, marking a shift from permissive allowlisting to deny-all — an admission that the allowlist approach was structurally unworkable once aliasing bypasses appeared.

Could the blanket import block in 3.1.0 still be bypassed?

The import keyword is only one way to load modules in Python. __import__(), importlib.import_module(), and exec() on attacker-supplied strings can all reach the OS layer without writing an import statement. If these builtins remain in the Pyodide execution globals, the same prompt-injection vector could bypass the new regex with no import statement at all.

Does the blanket import block limit future Flowise components?

The fix works because the CSV Agent’s Pyodide executor pre-imports pandas and numpy. Any future component that needs additional libraries in its execution context would require either expanding the pre-imported set — increasing the attack surface — or moving to namespace-level globals filtering, which is architecturally different from text-level regex blocking.