CVE-2026-91935

Executive Summary

CVE-2026-91935 is a Server-Side Request Forgery (SSRF) vulnerability (CWE-918) in Flowise, an open-source low-code platform for building LLM applications and chatflows. Versions prior to 3.1.4 fail to validate the baseURL parameter within chat-model nodes, allowing any authenticated user holding the chatflows:create or chatflows:update permissions to redirect outbound LLM provider requests to arbitrary hosts. The primary impact is credential theft: attackers can redirect requests carrying LLM provider API keys to cloud metadata services or internal hosts, resulting in high confidentiality and integrity impact (CVSS 8.3).

Technical Analysis

Flowise allows users to construct conversational AI workflows ("chatflows") composed of nodes, including nodes representing chat models from third-party LLM providers. These chat-model nodes accept a baseURL parameter, which configures the endpoint the node sends requests to. The intended function of baseURL is to allow deployments against self-hosted or alternative-compatible LLM gateways (for example, an OpenAI-compatible proxy on an internal network).

In Flowise versions before 3.1.4, the value supplied to baseURL is not validated against an allowlist, nor is it constrained to prevent requests to loopback, link-local, or private address ranges. Because the node subsequently transmits the configured LLM provider API key as an authentication header or request body to whatever host the baseURL points to, an attacker who can configure a chat-model node effectively controls the destination of a request that carries valid credentials.

This is a classic SSRF-adjacent credential-exfiltration pattern often described as "key-forwarding" or "credential relay": the server is induced to make a request it is authorized to make, but to an attacker-chosen destination. The vulnerability class (CWE-918) maps directly to the ability to redirect requests to cloud metadata services (e.g., link-local metadata endpoints) or arbitrary internal hosts reachable from the Flowise server's network context.

Key technical characteristics:

• Authentication requirement: The flaw is exploitable only by an authenticated principal. The NVD description specifies the chatflows:create or chatflows:update permission, meaning low-privilege but authenticated Flowise users — not anonymous internet attackers — are the threat actors. This is reflected in the CVSS vector PR:L (privileges required: low).
• No user interaction: UI:N — the attack requires no victim interaction once the malicious chatflow configuration is saved and triggered.
• Scope unchanged: S:U — the impacted component (the Flowise server) is the same security authority that makes the outbound request.
• High confidentiality and integrity, partial availability impact: C:H/I:H/A:L — confidentiality is impacted through API key exfiltration, integrity through redirecting provider calls, and availability partially through the potential to disrupt LLM-backed functionality.

The description does not enumerate specific API endpoints, controller functions, or file paths involved in the baseURL handling, and no such specifics are provided here. Analysis is therefore conducted at the vulnerability-class level: lack of server-side validation of a user-controlled URL parameter that is used as a request destination for credentialed outbound calls.

Flowise instances are frequently exposed on the public internet for convenience, which expands the population of systems where a merely low-privileged authenticated account is sufficient to reach the vulnerable functionality.

Exploitation Scenarios

No public PoC or exploit code is available for CVE-2026-91935; the chain below is inferred from the vulnerability class and the NVD description. No specific function, endpoint, or parameter names beyond baseURL and the permission scopes chatflows:create / chatflows:update are asserted, because the source description provides no others.

1) Reconnaissance / target identification The attacker identifies an exposed Flowise instance (commonly discoverable via HTTP fingerprinting of the Flowise web UI). The attacker obtains an authenticated account with at least chatflows:create or chatflows:update permission. This may be a legitimate low-privilege account, a shared account, or one obtained through separate means (e.g., weak credentials, credential reuse). No exploit of an authentication bypass is claimed here — the flaw assumes the attacker is already authenticated with the stated permissions.

2) Triggering the flaw class Using the Flowise chatflow editor, the attacker creates or updates a chatflow containing a chat-model node. In that node's configuration, the attacker supplies a malicious baseURL value. Because versions before 3.1.4 fail to validate this parameter, the Flowise server accepts the attacker-controlled destination without verifying it against an allowlist or blocking internal/reserved ranges. Candidate destinations an attacker would choose include:

• Cloud instance metadata services reachable from the Flowise host (e.g., link-local addresses used by major cloud providers), to attempt to harvest instance credentials or tokens.
• Internal hosts on the Flowise server's network that are not otherwise reachable from the attacker's position (port scanning / hitting internal-only services).

3) Payload / execution at the vulnerability-class level When the node is invoked (for example, when the chatflow is run or a chat is triggered), Flowise issues an outbound HTTP request to the attacker-supplied baseURL. Critically, the request is constructed by the chat-model node and therefore carries the configured LLM provider API key as part of the outbound authentication. The attacker points baseURL at a host they control or can observe (or at a metadata/internal endpoint), causing the Flowise server to transmit the API key — or to leak the key's value via subsequent behavior of the attacker-controlled endpoint — outside the intended trust boundary.

At the class level: SSRF via an unvalidated user-controlled URL parameter embedded in an authenticated, credentialed outbound request.

4) Post-exploitation impact The attacker obtains the targeted LLM provider API key(s). Consequences include:

• Direct abuse of the stolen key against the LLM provider (running up billing, accessing provider-side data associated with the key, or pivoting to other services the key authorizes).
• Use of the SSRF primitive to probe or reach internal hosts (network mapping, interaction with internal-only services).
• Potential disruption of LLM-backed chatflows if endpoints are redirected or broken.

No evidence of in-the-wild exploitation, public PoC, or Nuclei template exists for this CVE at the time of writing. The absence of a public PoC does not reduce risk given the simplicity of the required action (supplying a URL value in a UI) for any authenticated user with the relevant permissions.

Impact Assessment

• CVSS 8.3 (High) — CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L. Network-reachable, low attack complexity, low privileges required, no user interaction.
• Confidentiality (High): The core impact is exfiltration of LLM provider API keys. Because these keys often carry billing and data-access authority at the provider, compromise can have downstream financial and data exposure consequences beyond Flowise itself.
• Integrity (High): Attackers can redirect provider-bound traffic to arbitrary destinations, corrupting or rerouting LLM-backed application behavior and potentially feeding attacker-controlled responses into downstream consumers.
• Availability (Low): Redirected or broken endpoints can degrade or deny LLM-backed chatflow functionality, though the vulnerability is not primarily a denial-of-service primitive.
• Blast radius: Every Flowise instance below 3.1.4 that hosts multiple users with chatflow-creation/update rights, or that is exposed to the internet with any authenticated accounts, is exposed. The credential-theft impact means the blast radius extends beyond the Flowise deployment to the upstream LLM provider account(s) whose keys are stored in the affected nodes.
• System categorization: LLM application platforms frequently sit adjacent to sensitive internal services and hold valuable secrets; this raises the effective value of the SSRF primitive (internal host reachability) and the value of the exfiltrated keys.

Detection Guidance

Detection is challenging because the abuse occurs through legitimate authenticated configuration changes coupled with outbound requests that may resemble normal LLM API traffic. Detection should combine audit-log monitoring for baseURL changes, egress monitoring for unexpected destinations, and application-level logging.

Sigma Rule

title: Flowise Potential SSRF via baseURL Modification (CVE-2026-91935)
id: 8f6c1a2e-4d3b-4e9a-9c1f-202691935a01
status: experimental
description: Detects creation/update of Flowise chatflows referencing suspicious baseURL values that may indicate SSRF credential exfiltration attempts.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-91935
author: valtersit.com
date: 2026-01-01
logsource:
  product: flowise
  service: audit
detection:
  selection_action:
    action:
      - 'chatflows:create'
      - 'chatflows:update'
      - 'chatflow.create'
      - 'chatflow.update'
  selection_baseurl_suspicious:
    baseURL|contains:
      - '169.254.169.254'
      - 'metadata.google.internal'
      - 'metadata'
      - '127.0.0.1'
      - 'localhost'
      - '0.0.0.0'
      - '::1'
      - 'file://'
      - 'gopher://'
      - 'dict://'
      - '10.'
      - '192.168.'
      - '172.16.'
  selection_baseurl_external:
    baseURL|re: '^http://[^/]+'
  condition: selection_action and (selection_baseurl_suspicious or selection_baseurl_external)
  falsepositives:
    - Legitimate self-hosted or gateway deployments intentionally configured with internal baseURLs
    - Administrators configuring private OpenAI-compatible endpoints
level: medium
tags:
  - attack.t1190
  - cwe.918

YARA Rule

rule CVE_2026_91935_Flowise_baseURL_SSRF
{
    meta:
        description = "Detects Flowise chatflow configuration or log artifacts referencing suspicious baseURL values associated with CVE-2026-91935 SSRF"
        author = "valtersit.com"
        date = "2026-01-01"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-91935"
        cve = "CVE-2026-91935"

    strings:
        $baseurl = "baseURL" ascii wide nocase
        $meta_ip = "169.254.169.254" ascii wide
        $gcp_meta = "metadata.google.internal" ascii wide nocase
        $aws_meta = "metadata" ascii wide nocase
        $loopback = "127.0.0.1" ascii wide
        $priv10 = "10." ascii wide
        $priv192 = "192.168." ascii wide
        $priv172 = "172.16." ascii wide

    condition:
        $baseurl and 1 of ($meta_ip, $gcp_meta, $loopback, $priv10, $priv192, $priv172)
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-91935 Flowise SSRF baseURL Exfiltration Attempt"; flow:to_server,established; http.request_body; content:"baseURL"; nocase; pcre:"/(169\.254\.169\.254|metadata\.google\.internal|127\.0\.0\.1|192\.168\.|10\.|172\.16\.)/i"; reference:cve,2026-91935; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-91935; classtype:attempted-recon; sid:202691935; rev:1;)

alert http any any -> any any (msg:"Flowise Outbound Request to Cloud Metadata Endpoint (Possible CVE-2026-91935)"; flow:to_server,established; http.uri; content:"169.254.169.254"; nocase; reference:cve,2026-91935; classtype:attempted-recon; sid:202691936; rev:1;)

Note: because the exfiltration arrives as an outbound request from the Flowise server, also alert on server-initiated HTTP to link-local and RFC1918 destinations using a separate direction-aware rule in production tuning.

Elastic Detection

sequence by user.name with maxspan=5m
  [ any where event.category == "web" and event.action in ("chatflows:create", "chatflows:update") and process.name == "node" ]
  [ network where destination.address != null and
      (destination.address : ("169.254.169.254", "127.0.0.1", "::1", "0.0.0.0") or
       cidr_match(destination.address, "10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16", "169.254.0.0/16")) ]

This EQL correlates a chatflow create/update action by a user followed within five minutes by an outbound connection to a metadata, loopback, or private-range destination from the same host.

Splunk SPL Query

index=flowise OR index=network sourcetype=flowise:audit OR sourcetype=pan:traffic
| eval suspicious_baseurl=if(match(baseURL,"(?i)(169\.254\.169\.254|metadata\.google\.internal|127\.0\.0\.1|localhost|0\.0\.0\.0|::1|10\.|192\.168\.|172\.(1[6-9]|2[0-9]|3[01])\.)"),1,0)
| where suspicious_baseurl=1 OR match(action,"chatflows:(create|update)")
| stats count values(baseURL) as baseurls values(user) as users by host, action
| where count > 0
| table _time host action users baseurls count

Correlation view for outbound connections to metadata endpoints:

index=network dest_ip IN ("169.254.169.254","127.0.0.1")
| stats count by src_ip dest_ip dest_port
| where dest_port IN (80,443,8080)

Wazuh OSSEC Rule

<group name="flowise,ssrf,CVE-2026-91935,">
  <rule id="2026919" level="10">
    <decoded_as>json</decoded_as>
    <field name="action">chatflows:(create|update)</field>
    <field name="baseURL">\.(169\.254\.169\.254|metadata\.google\.internal|127\.0\.0\.1|localhost|192\.168\.|10\.|172\.(1[6-9]|2[0-9]|3[01])\.)</field>
    <description>CVE-2026-91935: Possible Flowise SSRF via suspicious baseURL in chatflow configuration</description>
    <mitre>
      <id>T1190</id>
    </mitre>
    <group>ssrf_attempt,</group>
  </rule>

  <rule id="2026920" level="12">
    <if_sid>2026919</if_sid>
    <field name="baseURL">169\.254\.169\.254|metadata\.google\.internal</field>
    <description>CVE-2026-91935: Flowise chatflow baseURL targets cloud metadata service — likely credential exfiltration attempt</description>
    <group>ssrf_attempt,credential_access,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 2/4 — CLAIMED. A single source (OSV) claims a fix. The patch has not been independently confirmed, and no CNA- or NVD-attributed vendor advisory was present in the supplied data. Treat the version boundary (< 3.1.4) as the best available signal, verify against the vendor before relying on it operationally.

Immediate mitigations (apply until upgrade is verified):

1. Restrict who holds chatflows:create / chatflows:update. These permissions are the gate for exploitation. Remove them from any non-essential or low-trust accounts; audit existing grant assignments.
2. Network egress controls. Enforce egress filtering from the Flowise server so it cannot reach link-local metadata endpoints (169.254.169.0/24) or unintended internal hosts. Where feasible, run Flowise in a network segment whose metadata service is disabled (e.g., IMDSv2 enforced / hop limit set to 1 on AWS, or metadata access blocked entirely).
3. Reduce exposure. Do not expose the Flowise UI directly to the internet; place it behind an authenticated reverse proxy / zero-trust access layer and limit reachable user populations.
4. Rotate LLM provider keys. If a malicious or unrecognized baseURL change is suspected, assume all LLM provider API keys configured in chat-model nodes were exposed and rotate them immediately.
5. Audit existing chatflows. Review stored chatflow definitions for chat-model nodes whose baseURL points to unexpected external, loopback, link-local, or private-range hosts.

Patch / upgrade steps:

1. Confirm the fixed version against the vendor (Flowise) release notes and changelog; the supplied data indicates 3.1.4 as the remediating version (OSV-sourced, unverified).
2. Back up chatflow definitions and the Flowise database.
3. Upgrade Flowise to 3.1.4 or later in a staging environment; verify that baseURL validation now rejects unauthorized/internal destinations.
4. Re-scan any existing chatflow configurations for anomalous baseURL values before promoting to production.
5. Roll forward to production and confirm the running version.

Long-term hardening:

• Adopt a strict allowlist for any user-supplied URL that the server dereferences, and block RFC1918, loopback, link-local, and other reserved ranges by default.
• Apply least privilege to platform permissions; avoid granting chatflow authoring rights broadly.
• Implement egress allowlisting (deny-by-default) for the Flowise host.
• Enable structured audit logging of configuration changes (who, when, what) and forward to the SIEM.
• Enforce cloud provider metadata hardening (IMDSv2, hop limit 1, or metadata disabled).
• Periodically rotate secrets and use short-lived, scoped credentials for LLM provider access wherever supported.

References

1. NVD — CVE-2026-91935: https://nvd.nist.gov/vuln/detail/CVE-2026-91935
2. CWE-918 — Server-Side Request Forgery (SSRF): https://cwe.mitre.org/data/definitions/918.html
3. OSV — source claiming the patch (single source, unverified): https://osv.dev/
4. MITRE ATT&CK — T1190 Exploit Public-Facing Application: https://attack.mitre.org/techniques/T1190/
5. Flowise project repository and release notes (verify version 3.1.4 fix): https://github.com/FlowiseAI/Flowise

Exploit-in-the-wild / threat actor note: No public PoC, exploit code, Nuclei template, or CISA KEV listing is associated with CVE-2026-91935 at the time of writing, and no threat actor campaign has been attributed. The report above is based on the vulnerability class and the NVD description; no exploitation in the wild is claimed.