AI Threat AlertCVE-2026-91935: Flowise: SSRF in chat-model baseURL leaks API keys
HIGHPoC AVAILABLECISA: ATTENDFlowise versions before 3.1.4 do not validate the baseURL parameter in chat-model nodes, so any authenticated user who can create or update chatflows can point model requests at an arbitrary host. That lets them capture the LLM provider API keys sent with those requests, or reach cloud metadata services and internal hosts to steal cloud credentials. Exploitation needs only low privileges and no user interaction, and the 8.3 CVSS reflects high confidentiality and integrity impact. Real-world pressure is currently modest: EPSS is 0.00388 (69th percentile), there is no public exploit or Nuclei template, and it is not in CISA KEV, though CISA SSVC rates it ATTEND. Upgrade to Flowise 3.1.4 or later, rotate any LLM provider keys stored in Flowise, and restrict chatflow create/update permissions to trusted users until patched.
What is the risk?
High, but not an emergency. The flaw is network-reachable, low complexity and needs only low privileges (chatflows:create or chatflows:update), so any compromised or malicious builder account is enough. Impact is concentrated on confidentiality: LLM provider keys, and potentially cloud instance credentials via metadata endpoints (e.g., 169.254.169.254) and access to internal services. Likelihood of exploitation is currently low to moderate: no public exploit, no scanner template, no KEV listing, EPSS in the 69th percentile. Risk rises sharply for multi-tenant or internet-exposed Flowise deployments that run on cloud VMs with permissive instance roles, or that grant builder rights broadly.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| Flowise | npm | — | No patch |
Do you use Flowise? You're affected.
How severe is it?
What is the attack surface?
What should I do?
1 step1) Upgrade Flowise to 3.1.4 or later. 2) Rotate all LLM provider API keys and any other credentials configured in Flowise, especially if untrusted users held chatflows:create or chatflows:update. 3) Restrict those permissions to trusted administrators and review existing chatflows for unexpected baseURL values. 4) Enforce IMDSv2 (or equivalent) with hop limit 1 and apply least-privilege instance roles. 5) Add egress filtering so the Flowise host can reach only approved LLM provider endpoints and cannot reach metadata addresses or internal ranges. 6) Detect: audit chatflow create/update events, alert on chat-model nodes whose baseURL is not an approved provider domain, and monitor outbound connections from Flowise to unknown hosts or link-local addresses. 7) Set provider-side spend limits and usage alerts to catch key abuse.
What does CISA's SSVC say?
Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-91935?
Flowise versions before 3.1.4 do not validate the baseURL parameter in chat-model nodes, so any authenticated user who can create or update chatflows can point model requests at an arbitrary host. That lets them capture the LLM provider API keys sent with those requests, or reach cloud metadata services and internal hosts to steal cloud credentials. Exploitation needs only low privileges and no user interaction, and the 8.3 CVSS reflects high confidentiality and integrity impact. Real-world pressure is currently modest: EPSS is 0.00388 (69th percentile), there is no public exploit or Nuclei template, and it is not in CISA KEV, though CISA SSVC rates it ATTEND. Upgrade to Flowise 3.1.4 or later, rotate any LLM provider keys stored in Flowise, and restrict chatflow create/update permissions to trusted users until patched.
Is CVE-2026-91935 actively exploited?
Proof-of-concept exploit code is publicly available for CVE-2026-91935, increasing the risk of exploitation.
How to fix CVE-2026-91935?
1) Upgrade Flowise to 3.1.4 or later. 2) Rotate all LLM provider API keys and any other credentials configured in Flowise, especially if untrusted users held chatflows:create or chatflows:update. 3) Restrict those permissions to trusted administrators and review existing chatflows for unexpected baseURL values. 4) Enforce IMDSv2 (or equivalent) with hop limit 1 and apply least-privilege instance roles. 5) Add egress filtering so the Flowise host can reach only approved LLM provider endpoints and cannot reach metadata addresses or internal ranges. 6) Detect: audit chatflow create/update events, alert on chat-model nodes whose baseURL is not an approved provider domain, and monitor outbound connections from Flowise to unknown hosts or link-local addresses. 7) Set provider-side spend limits and usage alerts to catch key abuse.
What systems are affected by CVE-2026-91935?
This vulnerability affects the following AI/ML architecture patterns: agent frameworks, low-code LLM orchestration, LLM application platforms, multi-tenant AI builders.
What is the CVSS score for CVE-2026-91935?
CVE-2026-91935 has a CVSS v3.1 base score of 8.3 (HIGH). The EPSS exploitation probability is 0.39%.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0012Valid AccountsAML.T0049Exploit Public-Facing ApplicationAML.T0083Credentials from AI Agent ConfigurationAML.T0098AI Agent Tool Credential HarvestingAML.T0106Exploitation for Credential AccessCompliance Controls Affected
What are the technical details?
Original Advisory
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.
Exploitation Scenario
An attacker obtains a low-privilege Flowise builder account, for example through phishing, a leaked credential or a malicious insider. They create or edit a chatflow containing a chat-model node and set its baseURL to an attacker-controlled server. When the flow runs, Flowise sends the request, including the stored LLM provider API key in the authorization header, to that server, and the attacker harvests the key. In a second variant, they set the baseURL to the cloud metadata service or an internal host to retrieve instance credentials or internal data through the model response path. They then use the stolen keys for unauthorized inference, resale or further cloud access.
Weaknesses (CWE)
CWE-918 — Server-Side Request Forgery: The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination.
- [Implementation, Operation] If there is a known list of applications, IP, hostname, and/or domains to which the product is allowed to communicate, then use allowlists to ensure that outgoing requests are restricted to these known entities. The allowlists could be in the application code or possibly enforced by firewalls or network segmentation [REF-1511].
- [Implementation, Operation] If the product is expected to be able to connect to arbitrary IP addresses or domains, consider using a denylist that includes private network addresses, internal domain names, etc. The denylist could be in the application code or possibly enforced by firewalls or network segmentation [REF-1511].
Source: MITRE CWE corpus.
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:LReferences
Timeline
Related Vulnerabilities
CVE-2025-7133810.0Flowise: unauthenticated file write enables RCE
Same package: flowiseCVE-2025-5952810.0Flowise: Unauthenticated RCE via MCP config injection
Same package: flowiseCVE-2025-619139.9Flowise: path traversal in file tools leads to RCE
Same package: flowiseCVE-2026-409339.9Flowise: RCE via MCP stdio command injection
Same package: flowiseCVE-2026-464429.9Flowise: sandbox escape enables authenticated RCE
Same package: flowise