Flowise CVE-2026-100610

Requires an authenticated low-privilege user account OR any valid Flowise API key on the target instance (PR:L) - it is not exploitable pre-authentication. The attacker must know the target chatflowId (for reads) or specific record UUIDs (for deletes); chatflowId is easily obtained because it is embedded in public /chatbot/<chatflowId> share links, materially lowering the barrier. The flaw exists on Flowise through 3.1.4 against default configurations of the affected upsert-history routes (GET /api/v1/upsert-history/:id, PATCH /api/v1/upsert-history) with no special feature toggle needed. Impact is limited to document-store upsert-history data; no code execution. Practical risk is highest in multi-tenant/multi-workspace or shared deployments and negligible in single-user self-hosted instances. No patched version exists, so mitigation requires access controls or upstream proxy authorization rules.

This is a genuine but bounded authorization flaw (CWE-639 IDOR), not a headline-critical issue despite the 7.7 rating. The CVSS 4.0 vector (AV:N/AC:L/PR:L/UI:N) confirms network-reachable, low-complexity exploitation by an already-authenticated low-privilege user or valid API key - so it is a post-authentication privilege/tenant-boundary problem, not an unauthenticated RCE. The vendor's VI:H/VA:H (integrity/availability high) appears generous: the impact is scoped to document-store upsert-history rows, so deletion harms specific records rather than the whole system; confidentiality (VC:H) is the strongest real impact because leaked flowData/result paramValues can contain embedding/vector-store/record-manager credentials. There is no EPSS score, no CISA KEV listing, and no public POC provided, so there is no signal of active or automatable mass exploitation - this is a targeted-abuse-by-insider/tenant risk rather than an internet-wide worming threat. Key mitigating fact and key aggravating fact conflict: the aggravating factor is that the required chatflowId is exposed publicly in /chatbot/<chatflowId> share links (lowering the practical bar), while the mitigating factor is that an attacker still needs a valid authenticated session or API key on the instance. Overall: real priority for multi-tenant/shared Flowise deployments, lower priority for single-tenant self-hosted instances.

A low-privilege authenticated user (or holder of any valid API key) on a shared Flowise instance harvests a target chatflowId from a public /chatbot/<chatflowId> share link, then calls GET /api/v1/upsert-history/:id to read another workspace's document-store upsert history - exposing embedding, vector-store and record-manager node paramValues that may include credentials. The same actor can call PATCH /api/v1/upsert-history with an array of record UUIDs to delete other tenants' history rows. No public exploit code is identified at time of analysis, but the attack requires only trivially-craftable authenticated HTTP requests (AC:L).