CVE-2026-70475
This CVE (CVSS 7.1) targets a missing authorization check on a single execution endpoint in Flowise — the PUT route that modifies execution state. The critical detail: adjacent endpoints (GET, DELETE, POST for executions) correctly implement checkAnyPermission() while this one doesn't. That's not ignorance of the security model — it's a copy-paste or refactoring error that dropped one middleware call. The fix in version 3.1.3 was adding that single line. The CVSS and EPSS scores reflect external threat modeling, but the actual risk profile is different. Within a Flowise workspace — where teams collaborate on AI workflows, share API credentials, and chain flows together — any authenticated user can now modify any execution's state and results. This transforms Flowise from a collaboration tool into a vector for lateral privilege escalation: altering execution metadata mid-flight can manipulate LLM outputs, bypass embedded approval gates, or corrupt audit trails. For organizations using Flowise in semi-automated decision support, this crosses from technical vulnerability into business-critical exposure. The workspace scoping appropriately limits blast radius (no cross-tenant access), but the horizontal access within a workspace is significant. The trivial fix — one middleware call — is actually a warning sign. It suggests developers manually apply permission checks to each endpoint rather than enforcing them architecturally. That process gap predicts additional similar omissions. Re-audit the execution API surface for other missing checks, and specifically look for routes that were previously secured but lost middleware during refactoring — those are harder to find than brand-new omissions. Prioritize this higher than CVSS suggests if your deployment uses multi-user workspaces with varied trust levels, which is the exact collaboration pattern Flowise enables.
Reviewed through automated stages and approved by a human before publication.