CVE-2026-41266: Flowise Information Disclosure Flaw

CVE-2026-41266 Overview

CVE-2026-41266 is a sensitive data exposure vulnerability affecting Flowise, a drag & drop user interface for building customized large language model (LLM) flows. The vulnerability exists in versions prior to 3.1.0 where the /api/v1/public-chatbotConfig/:id endpoint exposes sensitive data including API keys, HTTP authorization headers, and internal configuration without requiring any authentication.

Critical Impact

An attacker with knowledge of a chatflow UUID can retrieve credentials stored in password type fields and HTTP headers, leading to credential theft, unauthorized API access, and potential lateral movement within connected systems.

Affected Products

• Flowise versions prior to 3.1.0
• Self-hosted Flowise deployments with exposed public-chatbotConfig endpoints
• Flowise instances with stored API credentials for LLM providers

Discovery Timeline

• 2026-04-23 - CVE CVE-2026-41266 published to NVD
• 2026-04-23 - Last updated in NVD database

Technical Details for CVE-2026-41266

Vulnerability Analysis

This vulnerability is classified under CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor). The flaw resides in the public chatbot configuration endpoint which was designed to serve configuration data for embedded chatbots but inadvertently exposes sensitive credential information.

The vulnerable endpoint /api/v1/public-chatbotConfig/:id fails to implement authentication checks, allowing any unauthenticated user to query chatflow configurations by simply knowing or guessing the chatflow UUID. The returned data includes password-type fields that should have been filtered or redacted, exposing API keys for services like OpenAI, Anthropic, and other LLM providers, as well as custom HTTP authorization headers configured for external service integrations.

The network-accessible nature of this vulnerability means that any Flowise instance exposed to the internet is potentially vulnerable. No user interaction is required for exploitation, and the attack complexity is low since the attacker only needs to discover valid chatflow UUIDs.

Root Cause

The root cause of this vulnerability is missing authentication and authorization controls on the /api/v1/public-chatbotConfig/:id endpoint combined with inadequate data filtering. The endpoint was likely intended to provide limited public configuration data for chatbot embedding functionality, but the implementation failed to:

1. Implement authentication checks before serving configuration data
2. Filter or redact sensitive fields such as API keys and authorization headers
3. Distinguish between public-safe configuration data and sensitive credentials

Attack Vector

The attack vector is network-based and requires no authentication or user interaction. An attacker can exploit this vulnerability through the following approach:

The attacker first needs to discover valid chatflow UUIDs. These may be obtained through various means including enumeration attempts, leaked URLs in client-side JavaScript, or social engineering. Once a valid UUID is obtained, the attacker makes a direct HTTP GET request to the vulnerable endpoint. The server responds with the complete chatflow configuration including any stored API keys, HTTP headers with authorization tokens, and internal configuration details. These credentials can then be used to access connected LLM services, potentially incurring costs on the victim's accounts or accessing sensitive data processed through those services.

For detailed technical information, see the GitHub Security Advisory.

Detection Methods for CVE-2026-41266

Indicators of Compromise

• Unusual HTTP GET requests to /api/v1/public-chatbotConfig/ endpoints from external IP addresses
• Sequential or enumeration-style requests with varying UUID patterns
• Access log entries showing unauthenticated requests retrieving configuration data
• Unexpected usage or billing spikes on connected LLM provider accounts (OpenAI, Anthropic, etc.)

Detection Strategies

• Monitor web server access logs for requests to the /api/v1/public-chatbotConfig/ path from unauthorized sources
• Implement rate limiting and anomaly detection on public API endpoints
• Set up alerts for enumeration patterns targeting chatflow UUID endpoints
• Review LLM provider dashboards for unauthorized API key usage

Monitoring Recommendations

• Enable detailed access logging for all Flowise API endpoints
• Configure SIEM rules to detect mass requests to configuration endpoints
• Monitor connected third-party service accounts for unusual activity patterns
• Implement network-level monitoring for data exfiltration attempts

How to Mitigate CVE-2026-41266

Immediate Actions Required

• Upgrade Flowise to version 3.1.0 or later immediately
• Rotate all API keys and credentials that were stored in Flowise chatflow configurations
• Review access logs for evidence of exploitation prior to patching
• Audit connected LLM provider accounts for unauthorized usage

Patch Information

The vulnerability is fixed in Flowise version 3.1.0. Organizations should update to this version or later to remediate the vulnerability. The patch implements proper authentication checks and data filtering on the affected endpoint.

For additional details, refer to the GitHub Security Advisory.

Workarounds

• If immediate patching is not possible, restrict network access to Flowise instances using firewall rules or reverse proxy authentication
• Implement a Web Application Firewall (WAF) rule to block unauthenticated access to /api/v1/public-chatbotConfig/ endpoints
• Remove stored credentials from chatflow configurations and use environment variables or external secret management instead
• Place Flowise behind a VPN or zero-trust network access solution to limit exposure

# Example nginx configuration to block unauthenticated access to vulnerable endpoint
location /api/v1/public-chatbotConfig/ {
    # Block all external access to vulnerable endpoint
    deny all;
    # Or require authentication
    # auth_basic "Restricted Access";
    # auth_basic_user_file /etc/nginx/.htpasswd;
}