Summary
Flowise's SQLite Record Manager node allows attacker-controlled configuration to overwrite the intended database path and write attacker-influenced content to sensitive filesystem locations.
An authenticated attacker may use this behavior to achieve code execution when a privileged deployment later launches Chromium and processes configuration files, particularly when the published container runs as root.
Flowise's SQLite Record Manager node allows attacker-controlled configuration to overwrite the intended database path and write attacker-influenced content to sensitive filesystem locations.
An authenticated attacker may use this behavior to achieve code execution when a privileged deployment later launches Chromium and processes configuration files, particularly when the published container runs as root.
Affected context
The issue occurs in Flowise deployments using the SQLite Record Manager node where user-controlled additionalConfig is merged after the intended database configuration. Risk is increased when the application uses the published Docker image with elevated container privileges and when Chromium processes configuration files from writable filesystem locations. Exploitation also depends on an authenticated user being able to invoke or configure the affected node.
The issue occurs in Flowise deployments using the SQLite Record Manager node where user-controlled additionalConfig is merged after the intended database configuration. Risk is increased when the application uses the published Docker image with elevated container privileges and when Chromium processes configuration files from writable filesystem locations. Exploitation also depends on an authenticated user being able to invoke or configure the affected node.
Exploit preconditions
- Attack surface: Flowise workflows using the SQLite Record Manager node
- Required access: Authenticated access sufficient to configure or execute an affected flow
- Trigger point: SQLite database creation or writing followed by a Puppeteer-launched Chromium process
- Environmental condition: The process must have permission to write to a location later interpreted as Chromium configuration
- Why exploitation is possible: Untrusted configuration can override the intended database path, while attacker-controlled table and namespace values can influence database contents that are subsequently processed as configuration
- Attack surface: Flowise workflows using the SQLite Record Manager node
- Required access: Authenticated access sufficient to configure or execute an affected flow
- Trigger point: SQLite database creation or writing followed by a Puppeteer-launched Chromium process
- Environmental condition: The process must have permission to write to a location later interpreted as Chromium configuration
- Why exploitation is possible: Untrusted configuration can override the intended database path, while attacker-controlled table and namespace values can influence database contents that are subsequently processed as configuration
Why this happens
The vulnerable code spreads user-controlled additionalConfig after the intended database setting, allowing a caller to replace security-relevant configuration values such as the SQLite path. This insecure merge order breaks the intended trust boundary between application-controlled settings and user input.
When the resulting database content is written to a location consumed as executable or shell-interpreted Chromium configuration, attacker-controlled data can be treated as code. This behavior maps to CWE-94: Improper Control of Generation of Code, because data reaches a downstream interpreter without adequate restriction or separation.
The vulnerable code spreads user-controlled additionalConfig after the intended database setting, allowing a caller to replace security-relevant configuration values such as the SQLite path. This insecure merge order breaks the intended trust boundary between application-controlled settings and user input.
When the resulting database content is written to a location consumed as executable or shell-interpreted Chromium configuration, attacker-controlled data can be treated as code. This behavior maps to CWE-94: Improper Control of Generation of Code, because data reaches a downstream interpreter without adequate restriction or separation.
Potential impact
- An attacker could execute commands with the privileges of the Flowise or Chromium process
- A root-running container could be fully compromised
- Sensitive application data or credentials could be accessed
- The host or surrounding infrastructure could face increased risk if container isolation is weak
- Workflows and stored model-related configuration could be modified or disrupted
- An attacker could execute commands with the privileges of the Flowise or Chromium process
- A root-running container could be fully compromised
- Sensitive application data or credentials could be accessed
- The host or surrounding infrastructure could face increased risk if container isolation is weak
- Workflows and stored model-related configuration could be modified or disrupted
General mitigation guidance
Mitigation generally focuses on preserving ownership of security-sensitive configuration and preventing data from reaching executable configuration paths.
Defensive patterns include:
- Whitelisting accepted configuration properties instead of merging arbitrary user-provided objects
- Applying trusted values after any user-supplied configuration, or rejecting attempts to override protected settings
- Restricting SQLite database paths to an application-owned directory with canonical-path checks
- Separating generated data from directories consumed as interpreter or browser configuration
- Running containers and worker processes as non-root users with minimal filesystem permissions
- Using read-only filesystems and narrowly scoped writable volumes where practical
- Limiting authenticated users' ability to create, edit, or execute flows
- Treating database content and workflow metadata as data rather than executable configuration
Mitigation generally focuses on preserving ownership of security-sensitive configuration and preventing data from reaching executable configuration paths.
Defensive patterns include:
- Whitelisting accepted configuration properties instead of merging arbitrary user-provided objects
- Applying trusted values after any user-supplied configuration, or rejecting attempts to override protected settings
- Restricting SQLite database paths to an application-owned directory with canonical-path checks
- Separating generated data from directories consumed as interpreter or browser configuration
- Running containers and worker processes as non-root users with minimal filesystem permissions
- Using read-only filesystems and narrowly scoped writable volumes where practical
- Limiting authenticated users' ability to create, edit, or execute flows
- Treating database content and workflow metadata as data rather than executable configuration
How teams detect issues like this
Detection approaches can include:
- Static analysis for object spreads or configuration merges in which untrusted properties follow protected settings
- Code review checks for user-controlled filesystem paths, SQLite destinations, and writes to browser configuration directories
- Tests that attempt to override protected configuration fields and verify that the override is rejected
- Runtime monitoring for unexpected database files or writes in system and Chromium configuration paths
- Container policy checks for root execution, broad filesystem write permissions, and writable sensitive directories
- Audit logging for authenticated users who create or execute flows involving the SQLite Record Manager node
Automated security review tools can help identify unsafe merge patterns and data flows from workflow inputs to filesystem or interpreter boundaries.
Detection approaches can include:
- Static analysis for object spreads or configuration merges in which untrusted properties follow protected settings
- Code review checks for user-controlled filesystem paths, SQLite destinations, and writes to browser configuration directories
- Tests that attempt to override protected configuration fields and verify that the override is rejected
- Runtime monitoring for unexpected database files or writes in system and Chromium configuration paths
- Container policy checks for root execution, broad filesystem write permissions, and writable sensitive directories
- Audit logging for authenticated users who create or execute flows involving the SQLite Record Manager node
Automated security review tools can help identify unsafe merge patterns and data flows from workflow inputs to filesystem or interpreter boundaries.
