CVE-2026-70473: Flowise Information Disclosure Flaw

CVE-2026-70473 Overview

CVE-2026-70473 is a high-severity information disclosure vulnerability in Flowise, a drag-and-drop user interface for building customized large language model (LLM) flows. Versions prior to 3.1.3 expose the GET /api/v1/upsert-history endpoint without proper authorization scoping. Any authenticated user can retrieve the entire server-wide upsert history rather than data limited to their own user, tenant, or workspace.

The response can exceed 100MB and includes sensitive Vector Store configuration such as Qdrant server URLs and collection names. The issue is tracked under [CWE-200] (Exposure of Sensitive Information to an Unauthorized Actor) and is fixed in version 3.1.3.

Critical Impact
Authenticated attackers can harvest cross-tenant integration parameters and infrastructure details, enabling follow-on attacks against connected Vector Stores and LLM pipelines.

Affected Products

Flowise versions prior to 3.1.3
Flowise API endpoint GET /api/v1/upsert-history
Deployments integrating Vector Stores such as Qdrant

Discovery Timeline

2026-08-04 - CVE-2026-70473 published to NVD
2026-08-04 - Last updated in NVD database

Technical Details for CVE-2026-70473

Vulnerability Analysis

The vulnerability resides in the Flowise server's handling of the GET /api/v1/upsert-history endpoint. The controller returns the entire upsert history stored on the server without filtering by the requesting user's workspace, tenant, or project context. Any authenticated caller with low privileges can obtain records that belong to other tenants sharing the same Flowise instance.

Returned records contain integration metadata for Vector Stores, including Qdrant server URLs, collection names, and other connection parameters used to embed and retrieve data for LLM flows. Because response payloads can exceed 100MB with no pagination or record limits, a single request enumerates the full history of the multi-tenant deployment.

Root Cause

The root cause is missing tenant and workspace isolation in the upsert-history controller. The endpoint lacks authorization checks that constrain results to the caller's activeWorkspaceId. Related controllers in the same codebase also required workspace-scoped lookups, as shown in the patch that introduced getChatflowByIdForWorkspace and enforced workspaceId on checkIfChatflowHasChanged.

Attack Vector

An attacker requires only a low-privileged authenticated session on the Flowise instance. The attacker issues a single HTTP GET request to /api/v1/upsert-history and parses the returned JSON for Vector Store endpoints and credentials-adjacent metadata. Extracted Qdrant URLs and collection names can then be targeted directly if network-reachable, or used to craft privilege escalation and data exfiltration attacks against tenants that share the same host.

typescript

// Patch excerpt from packages/server/src/controllers/chatflows/index.ts
// Source: https://github.com/FlowiseAI/Flowise/commit/d81483b70c997ddf981acc9c49fbd9a02fa345cd

-        const apiResponse = await chatflowsService.checkIfChatflowHasChanged(req.params.id, req.params.lastUpdatedDateTime)
+        const workspaceId = req.user?.activeWorkspaceId
+        if (!workspaceId) {
+            throw new InternalFlowiseError(
+                StatusCodes.NOT_FOUND,
+                'Error: chatflowsController.checkIfChatflowHasChanged - active workspace ID not found!'
+            )
+        }
+        const apiResponse = await chatflowsService.checkIfChatflowHasChanged(req.params.id, req.params.lastUpdatedDateTime, workspaceId)

The patch enforces activeWorkspaceId on the request context and passes it into the service layer so records are scoped to the calling workspace. A parallel change in chat-messages/index.ts replaces getChatflowById with getChatflowByIdForWorkspace, applying the same workspace boundary at the query layer.

Detection Methods for CVE-2026-70473

Indicators of Compromise

HTTP GET requests to /api/v1/upsert-history with unusually large response bodies, often exceeding tens of megabytes.
Repeated calls to /api/v1/upsert-history from a single authenticated session or API key within a short time window.
Outbound connections from unrelated hosts to Qdrant or other Vector Store endpoints referenced in leaked configuration.

Detection Strategies

Inspect Flowise access logs for GET /api/v1/upsert-history responses and alert on response sizes above a baseline for the deployment.
Correlate API access with the authenticated user's workspaceId to detect cross-workspace record enumeration.
Compare the Flowise server version against the GitHub Release 3.1.3 to identify unpatched instances.

Monitoring Recommendations

Enable request and response logging on the Flowise API gateway or reverse proxy to capture endpoint access patterns.
Monitor egress connections from application hosts to Vector Store URLs and flag connections from IP addresses not associated with the owning tenant.
Track authentication events for low-privileged accounts that exhibit reconnaissance behavior against administrative endpoints.

How to Mitigate CVE-2026-70473

Immediate Actions Required

Upgrade Flowise to version 3.1.3 or later, which introduces workspace-scoped queries and authorization enforcement.
Rotate any Vector Store credentials, URLs, or collection identifiers that may have been exposed through the affected endpoint.
Audit historical access logs for prior requests to /api/v1/upsert-history to identify possible data exposure.

Patch Information

The fix is delivered in Flowise 3.1.3 via GitHub Pull Request #6170 and commit d81483b. The patch enforces activeWorkspaceId on affected controllers and introduces workspace-aware service methods such as getChatflowByIdForWorkspace. Full details are documented in GitHub Security Advisory GHSA-fr6g-7cq8-fg82.

Workarounds

Restrict access to /api/v1/upsert-history at the reverse proxy or API gateway layer until upgrade is possible.
Deploy separate Flowise instances per tenant or workspace to remove cross-tenant exposure surface.
Place Vector Store services on isolated network segments so leaked URLs are not directly reachable from untrusted networks.

bash

# Example NGINX block to restrict the vulnerable endpoint prior to upgrade
location = /api/v1/upsert-history {
    allow 10.0.0.0/24;   # trusted admin subnet
    deny all;
    proxy_pass http://flowise_backend;
}