CVE-2026-30820: Flowise header spoof auth bypass

CISO Take

Flowise, a widely-deployed drag-and-drop LLM workflow builder, allows any authenticated tenant to gain full administrative access by spoofing a single HTTP header: `x-request-from: internal`. Once escalated, the attacker can read all stored LLM provider credentials (OpenAI, Anthropic, etc.), manage API keys, and execute arbitrary custom functions — the blast radius is total compromise of every secret the Flowise instance holds. A public proof-of-concept is available and exploitation requires no specialized skills; CVSS 8.8 with AC:L/PR:L means any trial or low-privilege account is sufficient. Patch to Flowise 3.0.13 immediately, and as a stop-gap, configure your API gateway or WAF to strip or reject external requests bearing the `x-request-from: internal` header.

Sources: NVD GitHub Advisory ATLAS

What is the risk?

High risk in any multi-user or SaaS Flowise deployment. The attack is network-reachable, low-complexity, requires only a valid (low-privilege) account, and yields full administrative access including credential exfiltration and code execution via custom functions. Sixteen prior CVEs in this package indicate a pattern of security debt. Public PoC eliminates any exploitation barrier; expect opportunistic scanning within days of disclosure. Not yet in CISA KEV but the CVSS and PoC availability make active exploitation likely.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Flowise	npm	—	No patch

Do you use Flowise? You're affected.

How severe is it?

CVSS 3.1

8.8 / 10

EPSS

0.5%

chance of exploitation in 30 days

Higher than 38% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Trivial

Exploitation Confidence

medium

○ CISA SSVC: Public PoC

○ Public PoC indexed (trickest/cve)

Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AV Network

AC Low

PR Low

UI None

S Unchanged

C High

I High

A High

What should I do?

5 steps

Patch: Upgrade all Flowise instances to version 3.0.13 immediately — the fix removes trust in the x-request-from: internal header from unauthenticated/untrusted sources.
Interim WAF control: Add a rule to strip or block inbound HTTP requests containing x-request-from: internal header before they reach the Flowise service.
Credential rotation: Assume compromise of all API keys stored in any Flowise credential store running pre-3.0.13; rotate LLM provider keys, database credentials, and integration secrets.
Detection: Query access logs for any calls to /api/v1/apikey, /api/v1/credentials, or /api/v1/tools with this header from unexpected tenants.
Audit accounts: Review all tenant accounts — especially trial/low-privilege — for anomalous API activity in the period since the advisory was published (2026-03-07).

What does CISA's SSVC say?

Decision Attend

Exploitation poc

Automatable No

Technical Impact total

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Auth Bypass Data Extraction Code Execution Agent Framework API AML.T0012 - Valid Accounts AML.T0049 - Exploit Public-Facing Application AML.T0053 - AI Agent Tool Invocation AML.T0083 - Credentials from AI Agent Configuration AML.T0106 - Exploitation for Credential Access

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 9 - Risk management system

ISO 42001

A.6.2.3 - Access control for AI systems

NIST AI RMF

GOVERN 6.1 - Policies, processes, and procedures are in place for AI risk management

OWASP LLM Top 10

LLM07 - Insecure Plugin Design LLM08 - Excessive Agency

Frequently Asked Questions

What is CVE-2026-30820?

Flowise, a widely-deployed drag-and-drop LLM workflow builder, allows any authenticated tenant to gain full administrative access by spoofing a single HTTP header: `x-request-from: internal`. Once escalated, the attacker can read all stored LLM provider credentials (OpenAI, Anthropic, etc.), manage API keys, and execute arbitrary custom functions — the blast radius is total compromise of every secret the Flowise instance holds. A public proof-of-concept is available and exploitation requires no specialized skills; CVSS 8.8 with AC:L/PR:L means any trial or low-privilege account is sufficient. Patch to Flowise 3.0.13 immediately, and as a stop-gap, configure your API gateway or WAF to strip or reject external requests bearing the `x-request-from: internal` header.

Is CVE-2026-30820 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2026-30820, increasing the risk of exploitation.

How to fix CVE-2026-30820?

1. Patch: Upgrade all Flowise instances to version 3.0.13 immediately — the fix removes trust in the `x-request-from: internal` header from unauthenticated/untrusted sources. 2. Interim WAF control: Add a rule to strip or block inbound HTTP requests containing `x-request-from: internal` header before they reach the Flowise service. 3. Credential rotation: Assume compromise of all API keys stored in any Flowise credential store running pre-3.0.13; rotate LLM provider keys, database credentials, and integration secrets. 4. Detection: Query access logs for any calls to `/api/v1/apikey`, `/api/v1/credentials`, or `/api/v1/tools` with this header from unexpected tenants. 5. Audit accounts: Review all tenant accounts — especially trial/low-privilege — for anomalous API activity in the period since the advisory was published (2026-03-07).

What systems are affected by CVE-2026-30820?

This vulnerability affects the following AI/ML architecture patterns: Agent frameworks, LLM workflow orchestration, AI development platforms, Multi-tenant AI SaaS, RAG pipelines.

What is the CVSS score for CVE-2026-30820?

CVE-2026-30820 has a CVSS v3.1 base score of 8.8 (HIGH). The EPSS exploitation probability is 0.48%.

What is the AI security impact?

Affected AI Architectures

Agent frameworksLLM workflow orchestrationAI development platformsMulti-tenant AI SaaSRAG pipelines

MITRE ATLAS Techniques

AML.T0012 Valid Accounts

AML.T0049 Exploit Public-Facing Application

AML.T0053 AI Agent Tool Invocation

AML.T0083 Credentials from AI Agent Configuration

AML.T0106 Exploitation for Credential Access

Compliance Controls Affected

EU AI Act: Article 9

ISO 42001: A.6.2.3

NIST AI RMF: GOVERN 6.1

OWASP LLM Top 10: LLM07, LLM08

What are the technical details?

Original Advisory

Flowise is a drag & drop user interface to build a customized large language model flow. Prior to version 3.0.13, Flowise trusts any HTTP client that sets the header x-request-from: internal, allowing an authenticated tenant session to bypass all /api/v1/** authorization checks. With only a browser cookie, a low-privilege tenant can invoke internal administration endpoints (API key management, credential stores, custom function execution, etc.), effectively escalating privilege. This issue has been patched in version 3.0.13.

Exploitation Scenario

An attacker registers a free trial or obtains a low-privilege tenant account on a target Flowise instance. Using browser developer tools or a simple Python script, they replay authenticated requests to `GET /api/v1/credentials` and `GET /api/v1/apikey` with the header `x-request-from: internal` appended. Flowise's authorization middleware skips all permission checks and returns the full credential store — including production API keys for OpenAI, Anthropic, or other LLM providers. The attacker then uses those keys to exfiltrate data via direct LLM API calls, spin up parallel inference workloads (cost harvesting), or pivots to connected databases and SaaS tools. In a more destructive path, the attacker calls custom function execution endpoints to achieve remote code execution inside the Flowise container, enabling full host-level access in uncontainerized deployments.

Weaknesses (CWE)

CWE-863 Incorrect Authorization Primary

CWE-863 — Incorrect Authorization: The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.

[Architecture and Design] Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
[Architecture and Design] Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].

Source: MITRE CWE corpus.