Flowise EUVD-2026-87700

Requires possession of a valid but low-privileged Flowise API key that lacks the required flow permissions; the attacker then reaches the GET and DELETE chat message routes directly because those routes omit route-level RBAC enforcement. This is inherently a multi-user/multi-tenant condition - it only matters where API keys are issued to lower-trust parties who should not access all flows. Limiting factors: an attacker with no valid key cannot exploit it (PR:L, not pre-auth), impact is confined to chat message read/delete (no code execution, no availability loss), and single-operator deployments where one trusted party holds the keys face negligible real risk. Affects Flowise through 3.1.4.

This is a real but moderate-priority authorization flaw (CWE-862 missing route-level RBAC), not a critical emergency. The vendor CVSS 4.0 of 7.5 is inflated: it sets AT:P (an attack requirement) and UI:P (user interaction) that the description does not justify - exploitation is a direct API call by an already-provisioned low-privileged key, needing neither. It also sets VI:H/VA:H, but the actual integrity impact is limited to deleting chat messages (VI:L, not full compromise) and there is no availability loss (VA:H is unsupported). The dominant impact is confidentiality: exposure of chat histories, prompts, and model responses (C:H). All exploitation signals for real-world risk are absent - no EPSS score, not in CISA KEV, and no public exploit code identified at time of analysis - so this is 'no public exploit identified at time of analysis.' The key mitigating factor is PR:L: the attacker must already hold a valid API key, so this is a privilege-boundary/tenant-isolation failure among existing key holders rather than a pre-auth internet-wide bug. Net: elevate for multi-tenant Flowise deployments where API keys are distributed to lower-trust users; deprioritize for single-operator installs.

In a multi-tenant or team Flowise deployment, a user holding a valid but low-privileged API key (lacking permissions on a given flow) directly calls the GET chat message route for that flow and reads other users' chat histories, prompts, and model responses, then calls the DELETE route to remove messages. No exploit code is public and the attack requires only standard HTTP requests with the low-privileged key - no user interaction or special attack conditions.