CVE-2026-91935 in Flowise
Summary
by MITRE • 09/15/2026
Flowise before 3.1.4 fails to validate baseURL parameters in chat-model nodes, allowing authenticated users to redirect requests to arbitrary hosts. Attackers with chatflows:create or chatflows:update permissions can exfiltrate LLM provider API keys by redirecting requests to cloud metadata services or internal hosts.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/15/2026
The vulnerability identified in Flowise versions prior to 3.1.4 represents a critical security flaw rooted in improper input validation of the baseURL parameter within chat-model nodes. This architectural weakness allows authenticated users who possess either chatflows:create or chatflows:update permissions to manipulate how API requests are routed by specifying arbitrary hostnames instead of legitimate LLM provider endpoints. The core technical failure lies in the application's inability to enforce a strict allowlist or validate that the provided URL belongs to an expected domain, thereby bypassing intended network boundaries and enabling server-side request forgery scenarios where the victim system acts as a proxy for malicious actors.
From an operational perspective, this flaw facilitates severe data exfiltration attacks against LLM provider API keys. By redirecting requests to cloud metadata services such as AWS EC2 instance metadata or Azure managed identity endpoints, attackers can retrieve temporary security credentials stored on the server hosting Flowise. Similarly, directing traffic toward internal hosts allows for lateral movement within private networks if the Flowise deployment is accessible from those segments. The exploitation does not require privilege escalation beyond standard user permissions related to chatflow management, making it a high-risk vulnerability that compromises both external API secrets and potentially sensitive internal infrastructure data through SSRF-like mechanisms.
This issue aligns with CWE-20 Improper Input Validation as the root cause stems directly from insufficient sanitization of URL parameters. Furthermore, the exploitation technique maps closely to ATT&CK T1557 Adversary-in-the-Middle or more specifically T1046 Network Service Discovery when used for internal reconnaissance, and T1078 Valid Accounts if leveraging existing credentials. The ability to redirect outbound traffic to arbitrary destinations also touches upon CWE-918 Server-Side Request Forgery (SSRF) principles, even though the primary vector is through configuration manipulation rather than direct user input fields in a web form context.
Mitigation strategies must prioritize immediate patching to version 3.1.4 or later where this validation logic has been corrected. In environments where upgrading is not immediately feasible, network-level controls such as egress filtering should be implemented to restrict outbound connections from the Flowise server to only known and trusted LLM provider domains. Additionally, implementing strict URL parsing libraries that reject relative paths or non-HTTP schemes can provide a defensive layer against similar manipulation attempts. Security teams should also audit existing chatflows for any suspicious baseURL configurations and enforce least-privilege principles by restricting who holds permissions to create or update chat flows, thereby reducing the attack surface available to potential adversaries.