CVE-2026-67621

Executive Summary

CVE-2026-67621 is a missing authorization vulnerability in Flowise through version 3.1.4 that permits authenticated workspace members with only view-level permissions to invoke document store operations that should require elevated access. The flaw lies in unprotected mutation endpoints that handle document ingestion and vector database refresh operations, enabling low-privilege attackers to modify knowledge bases consumed by downstream chatflow applications, consume embedding API credits, and tamper with the integrity of AI-powered responses. With a CVSS score of 7.6 (High), the vulnerability is remotely exploitable over the network with low attack complexity and requires only low-privilege authentication, exposing organizations running Flowise in production to document/data integrity compromise and resource abuse.

Technical Analysis

Flowise is an open-source drag-and-drop tool for building LLM (large language model) applications and chatfl­ows. The application implements a role-based access control (RBAC) model for its workspace feature, designed to enforce granular permission levels—including view, edit, and admin—across shared document stores, chatflows, and related resources. Within this model, members holding only view-level permissions are intended to be able to read and monitor resources but not modify them.

The vulnerability arises from a server-side authorization enforcement gap. While the front-end user interface (UI) hides or disables mutation controls from view-only users, the corresponding backend routes—specifically the upsert and refresh document store endpoints—lack server-side authorization checks. These endpoints do not validate whether the authenticated principal possesses the mutational permissions required to ingest new documents or refresh vector database contents.

This is a classic example of CWE-862 (Missing Authorization). The application fails to enforce access control at the API layer, relying instead on client-side UI restrictions, which can be trivially bypassed. The NVD description explicitly states that attackers can issue "direct HTTP requests" to these routes, bypassing the UI entirely.

Attack surface characteristics:

• Authentication requirement: Low — the attacker must be an authenticated workspace member, but only at view-level permissions. No privileged account is needed.
• Network accessibility: The attack is executed remotely over the network (AV:N) against exposed Flowise instances.
• Attack complexity: Low (AC:L) — no special conditions or race conditions are required; a valid session token plus a crafted HTTP request suffices.
• Impact scope: Unchanged (UI:N) — the vulnerability does not cross trust boundaries; however, within the workspace the impact on integrity is high (I:H), confidentiality low (I:C→C:L), and availability low (A:L).

Technical mechanism at the code level:

Although the NVD description does not provide exact function names or file paths, the vulnerability class implies the following code-level pattern in the Flowise backend (likely built on Express.js, given the project's Node.js architecture):

1. Route registration: The routes for document store upsert and refresh are registered on an Express router.
2. Middleware stack: These routes are either (a) not placed behind the authorization middleware that checks for mutate/editor permissions, or (b) the authorization middleware is configured with a default-permit rule for authenticated users regardless of workspace role.
3. Handler logic: The controller handlers execute database mutations or vector store operations directly after authentication, without a secondary check on the user's permission level for the specific document store resource.

The result is that any authenticated user—including view-only members—can:

• POST to the upsert route with document ingestion payloads, causing new documents (or modified versions of existing documents) to be embedded and stored in the vector database.
• POST to the refresh route, triggering a re-embedding and refresh of the vector index contents.

These operations have cascading effects: they alter the semantic knowledge base that downstream chatflows query, consume API credits from configured LLM/embedding providers (e.g., OpenAI, Pinecone, etc.), and modify the factual grounding of AI responses.

Exploitation Scenarios

Scenario 1: Knowledge Base Poisoning via View-Only Account (Primary Attack Chain)

Reconnaissance (Step 1): The attacker enumerates the Flowise workspace to identify document stores. Using a valid view-level session (obtained via legitimate workspace invitation or credential compromise), the attacker queries the standard list endpoints (GET /api/v1/document-stores or similar) to obtain document store IDs and names. The attacker also fingerprints the upstream embedding provider and observes that embedding quotas are metered per-credential.

Weaponization/Trigger (Step 2): The attacker crafts a direct HTTP request to the unprotected mutation endpoint. A representative attack request using curl:

curl -X POST https://target.flowise.internal/api/v1/document-stores/{storeId}/upsert \
  -H "Authorization: Bearer {viewer_token}" \
  -H "Content-Type: application/json" \
  -d '{
    "documents": [
      {
        "content": "By policy update 2026, the internal provisioning deadline is January 1; all employees are granted two additional leave days.",
        "metadata": {"source": "unverified", "attacker": "true"}
      }
    ]
  }'

Because the route lacks the authorization middleware that would reject mutations by view-only users, the server processes the ingestion, runs the embedding pipeline against the configured provider, and persists the new vector entries into the document store index.

Execution/Post-exploitation (Step 3): The injected content now resides in the vector database. When downstream chatflows query this document store for retrieval-augmented generation (RAG), the poisoned content is surfaced as context, allowing the attacker to steer LLM outputs toward false or attacker-preferred information. This is a form of indirect prompt injection via data poisoning.

Impact: The attacker corrupts the knowledge base used by customer-facing or internal chat assistants, altering responses to present misinformation, leak internal context, or cause business disruption. Each upsert also burns embedding API credits, with the volume of ingested fake documents determining financial impact.

Scenario 2: Vector Database Refresh Abuse

Reconnaissance (Step 1): The attacker identifies a view-only workspace where document stores exist with stale indices.

Weaponization/Trigger (Step 2): The attacker sends a POST to the refresh route:

curl -X POST https://target.flowise.internal/api/v1/document-stores/{storeId}/refresh \
  -H "Authorization: Bearer {viewer_token}"

Execution (Step 3): This triggers a full re-embedding of the entire document store, consuming API credits proportional to the store's size. Repeated calls drain the organization's embedding budget.

Impact: Financial resource exhaustion; potential denial-of-service for legitimate chatflow users if rate limits are exceeded.

Scenario 3: Chained with Other Flaws

If the attacker already has a foothold (e.g., a view-only account), this vulnerability can be combined with SSRF or prompt injection vulnerabilities (if present in the environment) to further pivot, but the reported CVE alone provides the mutational primitive.

Impact Assessment

CVSS contextualization (score: 7.6, High):

• Confidentiality (C:L): Low direct confidentiality impact—the attacker does not directly exfiltrate data, but poisoning may cause downstream leakage of sensitive content via chat responses.
• Integrity (I:H): High integrity impact—the attacker can manipulate document stores and knowledge bases, altering the semantic content that governs AI/chatflow behavior.
• Availability (A:L): Low availability impact—resource consumption (embedding credits, compute) can degrade or disrupt service under repeated abuse.

Business impact:

• AI/LLM application integrity: Organizations deploying Flowise-based chatbots, internal knowledge assistants, or customer support agents face data-poisoning risk. Malicious content injected into document stores changes what the models "know," which can result in regulatory compliance violations (e.g., GDPR, HIPAA) if wrong patient/legal/business data is presented as authoritative, or reputational harm from incoherent or harmful outputs.
• Financial loss: Embedding API credits are metered; unauthorized ingestion and refresh operations incur direct costs that scale with document volume.
• Operational disruption: Refresh operations can lock the vector store during re-indexing, rendering chatflows briefly unavailable or returning incomplete results.

Affected systems:

• Flowise instances up to and including version 3.1.4 running in any deployment mode (Docker, npm, cloud VM) where the HTTP API is network-exposed.
• Multi-user workspaces are the primary at-risk configuration; single-user deployments have no second principal to abuse but are still exploitable if an attacker gains any authenticated session.

Blast radius: Any downstream consumer of the modified document stores—including production chatflows, APIs, or integrations that query the vector database—is affected.

Detection Guidance

Sigma Rule

title: Flowise Unauthorized Document Store Mutation Attempt
id: 7f4a9c2e-6b8d-4f5a-9e1c-3d2b8a5f6c1e
status: experimental
description: Detects direct HTTP requests to Flowise upsert and refresh document store endpoints by users who hold view-only permissions.
author: Valtersit Threat Intelligence
date: 2026/01/29
logsource:
  category: webserver
  product: flowise
detection:
  selection_mutation:
    cs-method:
      - 'POST'
    cs-uri-query:
      - '*/document-stores/*'
      - '*/document-store/*'
  selection_operation:
    cs-uri-query|contains:
      - '/upsert'
      - '/refresh'
  condition: selection_mutation and selection_operation
falsepositives:
  - Legitimate editors and admins performing authorized upsert/refresh operations
level: medium
tags:
  - attack.t1190
  - attack.t1567
  - cve.2026.67621
  - cwe.862

YARA Rule

rule flowise_unauthorized_docstore_exploit
{
    meta:
        author = "Valtersit Threat Intelligence"
        description = "Detects HTTP request patterns targeting Flowise document store upsert/refresh endpoints"
        cve = "CVE-2026-67621"
        cwe = "CWE-862"
        date = "2026-01-29"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-67621"
    strings:
        $upsert_path = "/upsert" ascii nocase
        $refresh_path = "/refresh" ascii nocase
        $doc_store_route = "/document-stores/" ascii nocase
        $auth_header = "authorization: bearer " ascii nocase
        $method_post = "POST" ascii nocase
    condition:
        uint16(0) == 0x0a0d and
        $method_post and
        ($upsert_path or $refresh_path) and
        $doc_store_route and
        $auth_header
}

Suricata IDS Rule

alert http any any -> $HOME_NET any (msg:"CVE-2026-67621 - Flowise Unauthorized Document Store Upsert/Refresh Attempt"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"document-stores"; nocase; http.uri; content:"/upsert"; nocase; http.uri; content:"/refresh"; nocase; classtype:attempted-admin; sid:700001; rev:1; reference:cve,2026-67621; metadata:created_at 2026_01_29, updated_at 2026_01_29;)

Elastic Detection

sequence by source.ip with maxspan=2m
  [network where process.name == "node" and destination.port == 3000 and network.direction == "ingress" and http.request.method == "POST" and http.request.body.content : "*document-stores*" and http.request.body.content : ("*upsert*", "*refresh*")]
  [authentication where event.action == "authenticated" and outcome == "success"]

Splunk SPL Query

index=web sourcetype=access_combined
| where like(uri, "%/document-stores/%") AND (like(uri, "%/upsert") OR like(uri, "%/refresh"))
| search method=POST
| eval low_priv_role = if(user_role == "viewer", "yes", "no")
| table _time, src_ip, user, user_role, uri, method, status
| where low_priv_role == "yes"
| sort - _time

Wazuh OSSEC Rule

<group name="flowise,">
  <rule id="100001" level="10">
    <decoded_as>json</decoded_as>
    <field name="event.module">access</field>
    <field name="source.ip">\.+</field>
    <field name="http.request.method">POST</field>
    <field name="url.path">\.*document-stores\.*</field>
    <field name="url.path">\.*(upsert|refresh)\.*</field>
    <description>Flowise unauthorized document store mutation attempt by view-only user</description>
    <group>cve-2026-67621,</group>
    <mitre>
      <id>T1190</id>
    </mitre>
  </rule>
</group>

Mitigation & Patch Guidance

Patch status: Confirmed unpatched. Patch confidence: 0/4 — no official vendor patch, hotfix, or advisory has been issued for CVE-2026-67621 as of this report. All Flowise versions through 3.1.4 are affected.

1. Immediate Mitigations (no patch available)

• Egress/ingress restrictions: Place the Flowise API behind a reverse proxy or API gateway (e.g., Nginx, Kong, AWS API Gateway) and configure network-level access control lists (ACLs) to permit only trusted IP ranges.
• Web Application Firewall (WAF) rules: Deploy WAF rules that block POST requests to URLs matching */document-stores/*/upsert and */document-stores/*/refresh when the source IP is outside the trusted admin network.
• Disable view-level member accounts: Until patched, revoke or suspend workspace members with view-only permissions to reduce the attack surface.
• Monitor embedding API consumption: Set hard spend alerts on embedding/LLM API quotas to detect anomalous ingestion volume.
• Periodic snapshot/backup: Maintain frequent backups of document store vector indices so that a poisoned store can be rolled back to a clean baseline.

2. Patch/Upgrade Steps

• Watch for Flowise release > 3.1.4: Subscribe to Flowise GitHub release notifications and CVE feeds. When a patched version is released, upgrade immediately.
• Vendor coordination: Monitor the official Flowise GitHub repository (github.com/FlowiseAI/Flowise) issue tracker for the security advisory and proposed fix.
• Test upgrade in staging: Validate the patched version against the existing document store configuration and chatflow workflows before production rollout.

3. Long-Term Hardening

• Server-side RBAC enforcement: Advocate for and verify that any future Flowise patch enforces authorization server-side on all mutation routes, not just UI-level hiding.
• Least-privilege principle: Audit all workspace memberships; convert view-only users to read-only access to document stores specifically, and remove any unnecessary accounts.
• Network segmentation: Run Flowise on an internal network segment with restricted inbound access from the internet; mandate VPN for all administrative access.
• Routine security testing: Conduct periodic penetration tests and API fuzzing against the Flowise deployment to detect similar authorization gaps in other routes.

References

1. NVD Entry — https://nvd.nist.gov/vuln/detail/CVE-2026-67621
2. Flowise Official Repository & Issue Tracker — https://github.com/FlowiseAI/Flowise (monitor for security advisories and patch announcements)
3. MITRE ATT&CK™ — T1190 Exploit Public-Facing Application — https://attack.mitre.org/techniques/T1190/
4. CWE-862 Missing Authorization — https://cwe.mitre.org/data/definitions/862.html
5. CISA Known Exploited Vulnerabilities Catalog (CISA KEV) — CVE-2026-67621 is not listed in the CISA KEV catalog as of this report's publication; no exploit-in-the-wild evidence has been publicly confirmed.