Summary
Flowise versions before 3.1.3 allowed unauthenticated requests to the prediction endpoint to inject properties into the execution context of public chatflows, even when API overrides were not enabled. An attacker could alter identifiers, conversation history, and values used by flow-node templates, potentially manipulating workflow behavior and application data.
Flowise versions before 3.1.3 allowed unauthenticated requests to the prediction endpoint to inject properties into the execution context of public chatflows, even when API overrides were not enabled. An attacker could alter identifiers, conversation history, and values used by flow-node templates, potentially manipulating workflow behavior and application data.
Affected context
The issue occurs in Flowise deployments exposing public chatflows through the unauthenticated /api/v1/prediction/:id endpoint. It becomes risky when request-supplied overrideConfig data is merged into internal flow configuration without confirming that API overrides are enabled, allowing user-controlled properties to influence flow execution and template resolution.
The issue occurs in Flowise deployments exposing public chatflows through the unauthenticated /api/v1/prediction/:id endpoint. It becomes risky when request-supplied overrideConfig data is merged into internal flow configuration without confirming that API overrides are enabled, allowing user-controlled properties to influence flow execution and template resolution.
Exploit preconditions
- Attack surface: Public Flowise prediction API
- Required access: Ability to send an unauthenticated request to a public chatflow endpoint
- Trigger point: Processing of the
overrideConfigobject during flow construction and execution - Why exploitation is possible: Request properties are unconditionally merged into internal flow context without enforcing the
apiOverrideStatusauthorization decision
- Attack surface: Public Flowise prediction API
- Required access: Ability to send an unauthenticated request to a public chatflow endpoint
- Trigger point: Processing of the
overrideConfigobject during flow construction and execution - Why exploitation is possible: Request properties are unconditionally merged into internal flow context without enforcing the
apiOverrideStatusauthorization decision
Why this happens
The underlying bug is an authorization and mass-assignment failure. Flowise accepted a client-controlled object and spread its properties into trusted internal structures without applying an allowlist or verifying that overrides were permitted for the target chatflow.
This maps primarily to CWE-639: Authorization Bypass Through User-Controlled Key, because attacker-controlled keys influence protected application state. It also relates to CWE-915: Improperly Controlled Modification of Dynamically-Managed Code Elements, as unrestricted properties are copied into dynamically managed flow configuration.
The underlying bug is an authorization and mass-assignment failure. Flowise accepted a client-controlled object and spread its properties into trusted internal structures without applying an allowlist or verifying that overrides were permitted for the target chatflow.
This maps primarily to CWE-639: Authorization Bypass Through User-Controlled Key, because attacker-controlled keys influence protected application state. It also relates to CWE-915: Improperly Controlled Modification of Dynamically-Managed Code Elements, as unrestricted properties are copied into dynamically managed flow configuration.
Potential impact
- An attacker may alter
chatId,sessionId, or conversation history - Flow execution behavior could be manipulated through
$flow.*template values - Chatflow responses or downstream processing could be influenced
- Application data integrity could be reduced
- Abuse of public workflows could increase operational cost or cause denial of service
- Sensitive workflow behavior or information could be exposed, depending on node configuration
- An attacker may alter
chatId,sessionId, or conversation history - Flow execution behavior could be manipulated through
$flow.*template values - Chatflow responses or downstream processing could be influenced
- Application data integrity could be reduced
- Abuse of public workflows could increase operational cost or cause denial of service
- Sensitive workflow behavior or information could be exposed, depending on node configuration
General mitigation guidance
Mitigation generally focuses on enforcing authorization before accepting any client-provided flow overrides and reducing the amount of request data treated as trusted.
Common defensive patterns include:
- Require an explicit, server-enforced authorization decision before processing overrides
- Accept only narrowly allowlisted, documented properties
- Reject attempts to modify identifiers, history, execution metadata, or other protected fields
- Validate override values against strict type, length, and content constraints
- Keep server-owned flow context separate from user-controlled request data
- Apply least-privilege permissions to workflow nodes and downstream integrations
- Log rejected override attempts and anomalous changes to flow context
Mitigation generally focuses on enforcing authorization before accepting any client-provided flow overrides and reducing the amount of request data treated as trusted.
Common defensive patterns include:
- Require an explicit, server-enforced authorization decision before processing overrides
- Accept only narrowly allowlisted, documented properties
- Reject attempts to modify identifiers, history, execution metadata, or other protected fields
- Validate override values against strict type, length, and content constraints
- Keep server-owned flow context separate from user-controlled request data
- Apply least-privilege permissions to workflow nodes and downstream integrations
- Log rejected override attempts and anomalous changes to flow context
How teams detect issues like this
Organizations can identify similar issues through:
- Static analysis and code review searches for unrestricted object spread or mass assignment from HTTP request bodies
- Checks confirming authorization decisions occur before request data is merged into trusted state
- Tests that submit unexpected keys to public and authenticated workflow endpoints
- API schema and policy enforcement that rejects undocumented or protected properties
- Runtime monitoring for unusual changes to session identifiers, chat history, or template-resolved values
Automated security review tools may help flag user-controlled object merges, missing allowlists, and authorization checks that occur after state mutation.
Organizations can identify similar issues through:
- Static analysis and code review searches for unrestricted object spread or mass assignment from HTTP request bodies
- Checks confirming authorization decisions occur before request data is merged into trusted state
- Tests that submit unexpected keys to public and authenticated workflow endpoints
- API schema and policy enforcement that rejects undocumented or protected properties
- Runtime monitoring for unusual changes to session identifiers, chat history, or template-resolved values
Automated security review tools may help flag user-controlled object merges, missing allowlists, and authorization checks that occur after state mutation.
