CVE-2026-30820: Flowise Privilege Escalation Vulnerability

CVE-2026-30820 Overview

CVE-2026-30820 is an Authorization Bypass vulnerability affecting Flowise, a drag & drop user interface for building customized large language model flows. 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.

Critical Impact

Low-privilege authenticated users can escalate to administrative access by spoofing a trusted internal header, compromising API keys, credential stores, and enabling arbitrary custom function execution.

Affected Products

• Flowise versions prior to 3.0.13
• FlowiseAI Flowise (all deployments without proper header validation)
• Self-hosted and cloud-based Flowise LLM flow builder instances

Discovery Timeline

• 2026-03-07 - CVE CVE-2026-30820 published to NVD
• 2026-03-11 - Last updated in NVD database

Technical Details for CVE-2026-30820

Vulnerability Analysis

This vulnerability is classified as CWE-863 (Incorrect Authorization), where the application fails to properly verify user privileges before granting access to protected resources. The fundamental flaw lies in Flowise's trust model for internal requests - the application accepts the x-request-from: internal HTTP header at face value without validating whether the request actually originates from a trusted internal service.

When a request arrives at any /api/v1/** endpoint, the authorization middleware checks for this header. If present and set to "internal", the middleware bypasses all tenant-level authorization checks, granting full administrative access to the request. This design assumes that only legitimate internal services would set this header, but any HTTP client can trivially spoof this header value.

The attack requires minimal prerequisites: the attacker only needs a valid low-privilege tenant session (browser cookie). From there, they can craft requests with the spoofed header to access administrative functionality including API key management, credential stores, and custom function execution capabilities.

Root Cause

The root cause is improper trust boundary implementation in the authorization middleware. The application fails to distinguish between genuinely internal service-to-service requests and external client requests that merely claim to be internal via a user-controllable HTTP header. HTTP headers can be arbitrarily set by any client, making them unsuitable as a sole mechanism for authorization decisions without additional validation such as mutual TLS, signed tokens, or network-layer restrictions.

Attack Vector

The attack is network-based and requires low privilege (authenticated tenant session). An attacker with a valid session cookie can manipulate HTTP requests using browser developer tools, proxy tools like Burp Suite, or simple curl commands. By adding the x-request-from: internal header to any API request, the attacker bypasses tenant authorization and gains access to administrative endpoints.

The exploitation flow involves:

1. Authenticating as a low-privilege tenant user
2. Intercepting or crafting requests to /api/v1/** endpoints
3. Adding the x-request-from: internal header to the request
4. Accessing administrative functions such as API key management, credential retrieval, or custom function execution

This vulnerability enables vertical privilege escalation, allowing a standard tenant to perform administrative operations that should be restricted to system administrators. For additional technical details, see the GitHub Security Advisory GHSA-wvhq-wp8g-c7vq.

Detection Methods for CVE-2026-30820

Indicators of Compromise

• Unusual API requests to administrative endpoints (/api/v1/apikey, /api/v1/credentials, /api/v1/functions) from tenant user sessions
• HTTP logs showing the x-request-from: internal header originating from external IP addresses or non-service user agents
• Tenant users accessing credential stores or API key management functions they should not have permission to view
• Unexpected modifications to API keys, credentials, or custom functions by non-administrative users

Detection Strategies

• Implement logging and alerting for any requests containing the x-request-from: internal header that originate from external networks
• Monitor administrative endpoint access patterns and flag requests from tenant sessions that suddenly gain elevated privileges
• Deploy Web Application Firewall (WAF) rules to detect and block requests with suspicious header combinations from external clients
• Correlate authentication logs with API access logs to identify privilege escalation attempts

Monitoring Recommendations

• Enable verbose HTTP request logging including all headers for /api/v1/** endpoints
• Configure alerts for administrative API calls from tenant-level authenticated sessions
• Review access logs regularly for patterns indicating authorization bypass attempts
• Implement anomaly detection for users accessing endpoints outside their normal permission scope

How to Mitigate CVE-2026-30820

Immediate Actions Required

• Upgrade Flowise to version 3.0.13 or later immediately
• Audit access logs for signs of exploitation prior to patching
• Review and rotate any API keys or credentials that may have been accessed by unauthorized users
• Implement network-level restrictions to limit which systems can send requests with internal headers

Patch Information

This vulnerability has been addressed in Flowise version 3.0.13. The patch removes the insecure reliance on the user-controllable x-request-from header for authorization decisions. Organizations should update to the patched version as the primary remediation step.

For patch details, refer to the Flowise 3.0.13 Release and the GitHub Security Advisory.

Workarounds

• Deploy a reverse proxy or WAF in front of Flowise to strip or reject the x-request-from header from external requests
• Implement network segmentation to ensure administrative endpoints are only accessible from trusted internal networks
• Use additional authentication mechanisms for administrative functions until the patch can be applied
• Consider temporarily disabling public access to Flowise instances until upgrade is complete

# Example: Nginx configuration to strip the x-request-from header
# Add to your Flowise reverse proxy configuration
location /api/v1/ {
    proxy_set_header x-request-from "";
    proxy_pass http://flowise_backend;
}