Flowise Missing Authorization on Execution Update Endpoint

Technical Analysis

The `PUT /api/v1/executions/:id` route in packages/server/src/routes/executions/index.ts omits the `checkAnyPermission('executions:update')`-style middleware applied to the GET and DELETE routes for the same resource, a classic CWE-862 missing authorization defect. Any caller possessing a valid but low-privileged API key can send a crafted PUT request to overwrite the `state`, `data`, and other metadata fields of an execution record without holding the intended permission. Because Flowise executions represent the recorded state/output of agent or workflow runs, an attacker can falsify execution results (e.g., mark a failed run as FINISHED, inject fabricated output data), potentially deceiving downstream consumers, automations, or human reviewers relying on execution history as ground truth. This crosses a trust boundary within the multi-tenant/workspace model where permission scoping is expected to prevent lateral tampering between users of differing privilege levels.

Affected Systems

Flowise, flowise-components

Detection Signatures

• PUT requests to /api/v1/executions/ or /api/v1/executions/:id from accounts lacking executions:update-equivalent permission
• API access logs showing execution state changes not preceded by corresponding workflow run completion events
• Unexpected transitions of execution state fields (e.g., to FINISHED) without matching orchestrator activity
• Audit trail showing execution 'data' field modified by user/API key different from the execution's original creator

Remediation Steps

1. 1

   Upgrade Flowise

   Update to a patched Flowise release beyond 3.1.2 that adds proper checkAnyPermission middleware to the PUT executions endpoint.

2. 2

   Add authorization middleware

   If self-hosting an affected version, apply a hotfix/reverse proxy rule enforcing an 'executions:update' (or equivalent) permission check before allowing PUT requests to /api/v1/executions.

3. 3

   Audit execution history

   Review execution records for unexpected state or data modifications inconsistent with actual workflow run activity to detect prior exploitation.

4. 4

   Restrict API key scopes

   Apply least-privilege API keys and monitor for keys performing operations outside their expected permission set.

5. 5

   Enable request logging/alerting

   Add monitoring for PUT calls to execution endpoints correlated with the calling principal's granted permissions to detect bypass attempts.