Summary
Flowise contains a code injection vulnerability in the CSVAgent that places attacker-controlled CSV content directly into Python code executed by Pyodide. An authenticated attacker who can submit or influence CSV input may execute arbitrary operating system commands with the privileges of the Flowise container.
Flowise contains a code injection vulnerability in the CSVAgent that places attacker-controlled CSV content directly into Python code executed by Pyodide. An authenticated attacker who can submit or influence CSV input may execute arbitrary operating system commands with the privileges of the Flowise container.
Affected context
The vulnerability occurs in Flowise deployments using the CSVAgent component when CSV-derived content is embedded into executable Python before execution by Pyodide. It is especially risky where authenticated users can create, upload, or otherwise control CSV data processed by the agent, and where the container grants elevated privileges.
The vulnerability occurs in Flowise deployments using the CSVAgent component when CSV-derived content is embedded into executable Python before execution by Pyodide. It is especially risky where authenticated users can create, upload, or otherwise control CSV data processed by the agent, and where the container grants elevated privileges.
Exploit preconditions
- Attack surface: Flowise CSVAgent data-processing workflow
- Required access: Authenticated access capable of supplying or modifying CSV input
- Trigger point: Construction and execution of the initial Python code block in Pyodide
- Why exploitation is possible: CSV content is interpolated into executable Python without adequate neutralization or structural validation, while later validation applies only to subsequently generated code
- Attack surface: Flowise CSVAgent data-processing workflow
- Required access: Authenticated access capable of supplying or modifying CSV input
- Trigger point: Construction and execution of the initial Python code block in Pyodide
- Why exploitation is possible: CSV content is interpolated into executable Python without adequate neutralization or structural validation, while later validation applies only to subsequently generated code
Why this happens
The underlying flaw is the direct interpolation of attacker-controlled CSV content into a Python source-code string. This mixes data and executable instructions, allowing specially crafted input to alter the intended program structure before execution. The later denylist-based validation does not protect the initial generated code block, mapping the issue to CWE-94: Improper Control of Generation of Code (Code Injection).
The underlying flaw is the direct interpolation of attacker-controlled CSV content into a Python source-code string. This mixes data and executable instructions, allowing specially crafted input to alter the intended program structure before execution. The later denylist-based validation does not protect the initial generated code block, mapping the issue to CWE-94: Improper Control of Generation of Code (Code Injection).
Potential impact
- An attacker may execute arbitrary operating system commands in the Flowise container
- The application runtime could be compromised
- Confidential data accessible to the container could be disclosed or modified
- Container credentials or connected services could be abused
- Attackers could attempt lateral movement or persistence, depending on deployment permissions
- An attacker may execute arbitrary operating system commands in the Flowise container
- The application runtime could be compromised
- Confidential data accessible to the container could be disclosed or modified
- Container credentials or connected services could be abused
- Attackers could attempt lateral movement or persistence, depending on deployment permissions
General mitigation guidance
Mitigation typically focuses on preserving a strict separation between untrusted data and executable code.
Common defensive patterns include:
- Passing CSV values through data-only APIs rather than source-code interpolation
- Using parameterized interfaces, structured objects, or safe serialization formats
- Applying context-appropriate encoding and escaping where code generation cannot be avoided
- Validating input structure and length before processing, without relying on denylists alone
- Restricting Pyodide and JavaScript bridge capabilities when they are not required
- Running the application with least privilege and minimizing container filesystem, process, and network permissions
- Enforcing authenticated workflow and data-upload authorization boundaries
Mitigation typically focuses on preserving a strict separation between untrusted data and executable code.
Common defensive patterns include:
- Passing CSV values through data-only APIs rather than source-code interpolation
- Using parameterized interfaces, structured objects, or safe serialization formats
- Applying context-appropriate encoding and escaping where code generation cannot be avoided
- Validating input structure and length before processing, without relying on denylists alone
- Restricting Pyodide and JavaScript bridge capabilities when they are not required
- Running the application with least privilege and minimizing container filesystem, process, and network permissions
- Enforcing authenticated workflow and data-upload authorization boundaries
How teams detect issues like this
Organizations can look for code-injection risks through:
- Static analysis rules identifying string interpolation or concatenation of external input into Python or other executable-language source
- Code review signals such as generated code containing user-controlled values, denylist-only validation, or validation performed after code construction
- Tests that submit boundary characters and structurally invalid data to verify that inputs remain data rather than becoming executable syntax
- Runtime monitoring for unexpected child-process creation, shell activity, or unusual use of language-runtime bridges
- Policy enforcement that prohibits dynamic code generation from untrusted input unless a reviewed sandbox and strict data interface are present
- Automated security review tools that flag dangerous code-construction patterns for manual assessment
Organizations can look for code-injection risks through:
- Static analysis rules identifying string interpolation or concatenation of external input into Python or other executable-language source
- Code review signals such as generated code containing user-controlled values, denylist-only validation, or validation performed after code construction
- Tests that submit boundary characters and structurally invalid data to verify that inputs remain data rather than becoming executable syntax
- Runtime monitoring for unexpected child-process creation, shell activity, or unusual use of language-runtime bridges
- Policy enforcement that prohibits dynamic code generation from untrusted input unless a reviewed sandbox and strict data interface are present
- Automated security review tools that flag dangerous code-construction patterns for manual assessment
