CVE-2026-67620

Executive Summary

CVE-2026-67620 is a server-side request forgery (SSRF) vulnerability affecting Flowise up to and including version 3.1.4, a popular open-source platform for building LLM-based chatflow applications. The flaw resides in the SSRF guard implemented in httpSecurity.ts, where the default deny-list fails to include the Oracle Cloud Infrastructure (OCI) metadata endpoint (192.0.0.192) and the Alibaba Cloud metadata endpoint (100.100.100.200), permitting authenticated attackers — and potentially unauthenticated ones under specific configurations — to force the server into issuing GET requests to cloud instance metadata services. Successful exploitation results in the exfiltration of instance identity documents and temporary role credentials, enabling lateral movement within the cloud environment. With a CVSS score of 7.7 (High), this vulnerability poses a significant risk to organizations deploying Flowise on OCI or Alibaba Cloud infrastructure, compounded by the absence of any vendor patch or workaround.

Technical Analysis

The vulnerability exists within Flowise's SSRF protection layer, specifically in the httpSecurity.ts module. This module implements a guard mechanism designed to prevent the server from making requests to internal or reserved IP addresses — a standard countermeasure against SSRF. The guard relies on a static deny-list of IP ranges (DEFAULT_DENY_LIST) that is consulted prior to executing any user-controlled URL fetch.

The flaw is two-fold:

1. Incomplete Deny-List: The DEFAULT_DENY_LIST omits two critical cloud metadata IP ranges:

   • 192.0.0.192 — Oracle Cloud Infrastructure (OCI) instance metadata service (IMDS) endpoint. This address is in the 192.0.0.0/24 range, which is not IANA-reserved for private use but is specifically designated by OCI for its metadata service.
   • 100.100.100.200 — Alibaba Cloud ECS metadata service endpoint. This is a public-looking IP that is, in practice, only routable within Alibaba Cloud's internal network, but it is not covered by standard private IP deny-lists (RFC 1918 ranges are 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16).

   Because these addresses are not in the deny-list, requests to them pass validation unimpeded.

2. Redirect-Based Bypass: The SSRF guard fails to re-validate URLs after processing HTTP redirects. Even if an initial URL is blocked, an attacker can use a redirect chain — e.g., a public URL that 302-redirects to http://100.100.100.200/latest/meta-data/ — to bypass the deny-list entirely. The guard only inspects the original request URL, not the final destination.

Attack Surface: The vulnerable code path is exposed through the fetch-links API endpoint. This endpoint accepts a url parameter and instructs the server to retrieve that URL's content. In Flowrise, URL-fetching nodes (e.g., "Link Reader" or "Custom API" nodes) are legitimate features used in chatflows to allow the LLM to access external resources. The fetch-links endpoint is designed to support these nodes.

Authentication Requirement: By default, the API requires authentication. However, if a chatflow is published as "public" (which is a common configuration for customer-facing chatbots), the underlying URL-fetching nodes operate without an authentication token. In such cases, an unauthenticated remote attacker can interact with the fetch-links endpoint directly.

Code-Level Insight: The vulnerable logic in httpSecurity.ts resembles the following pseudo-code:

const DEFAULT_DENY_LIST = [
  '0.0.0.0/8', '10.0.0.0/8', '127.0.0.0/8', '169.254.0.0/16',
  '172.16.0.0/12', '192.168.0.0/16', '::1/128', 'fc00::/7', ...
]; // Missing: 192.0.0.192/32 and 100.100.100.200/32

function validateUrl(requestUrl) {
  const host = parseHost(requestUrl);
  const ip = dnsResolve(host);
  if (isInDenyList(ip)) throw new Error('Blocked');
  
  // Fetch follows redirects without re-validation
  const response = fetch(requestUrl, { redirect: 'follow' });
  return response.text();
}

The redirect: 'follow' setting combined with the incomplete list creates the bypass chain.

Exploitation Scenarios

Scenario 1: Authenticated Attack (OCI Deployment)

1. Reconnaissance: The attacker identifies a publicly exposed Flowise instance (e.g., via Shodan search for http.title:"Flowise" or port scanning). They enumerate the /api/v1/prediction and /api/v1/fetch-links endpoints to confirm the software version (e.g., via response headers or error messages).
2. Authentication: The attacker obtains or compromises valid credentials (e.g., default admin credentials, API key leakage in client-side JavaScript, or brute-force of weak passwords).
3. Weaponization — Direct Request: The attacker crafts the following HTTP request:

   GET /api/v1/fetch-links?url=http://192.0.0.192/opc/v2/instance/ HTTP/1.1
   Host: target-flowise.example.com
   Authorization: Bearer <valid_token>
   

   Because 192.0.0.192 is not in the deny-list, the request passes validation. The server responds with the OCI instance metadata document (JSON), containing the instance ID, compartment OCID, region, and other sensitive details.
4. Credential Theft: In a second request, the attacker targets the dynamic credentials endpoint:

   GET /api/v1/fetch-links?url=http://192.0.0.192/opc/v2/instance/bv-metadata/
   

   This returns temporary role credentials (derived from the instance principle) — an access key, secret key, and session token. These are valid for a limited window (typically 1 hour) but allow the attacker to authenticate to the OCI API as the compromised instance.
5. Post-Exploitation: Using stolen credentials, the attacker calls OCI APIs (iam, compute, objectstorage) to enumerate resources, exfiltrate data from object storage buckets, or spawn malicious compute instances — all billed to the victim's tenancy.

Scenario 2: Unauthenticated Attack (Alibaba Cloud)

1. Reconnaissance: The attacker uses Shodan to find Flowise instances with chatflow in the response body, indicating a public chatflow is deployed. They check if the "Link Reader" node is enabled by sending a simple test URL to the fetch-links endpoint:

   GET /api/v1/fetch-links?url=http://example.com HTTP/1.1
   

   If the response contains example.com content, the endpoint is accessible without authentication.
2. Redirect-Based Bypass: The attacker hosts a URL (e.g., http://attacker.com/redirect-to-alibaba) that returns a 302 Found redirect to http://100.100.100.200/latest/meta-data/. The initial URL passes the deny-list check (since attacker.com is public), and the server follows the redirect to the Alibaba metadata service.
3. Data Exfiltration: The server fetches the metadata, including:

   /latest/meta-data/ram/security-credentials/<role-name>
   

   The response contains the STS token and access keys for the attached RAM role.
4. Impact: The attacker now has privileged access to Alibaba Cloud resources (OSS buckets, ECS instances, RDS databases) associated with the compromised role.

General Note: The attack can be fully automated. The attacker scripts the POST/GET requests with a loop to exhaustively enumerate metadata endpoints (/latest/meta-data/* on AWS-like services, /opc/v2/* on OCI) and parse the JSON responses for credential fields.

Impact Assessment

The CVSS vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N yields a base score of 7.7 (High). The most significant component is C:H (high confidentiality impact), reflecting the exposure of instance metadata and role-based cloud credentials. Integrity and availability are unaffected (I:N/A:N), but the scope change (S:C) means the compromise extends beyond the Flowise application into the cloud provider environment.

Business Impact:

• Cloud Account Takeover Risk: Stolen role credentials can grant broad access to cloud services, enabling data exfiltration (e.g., customer PII, proprietary models), resource hijacking (cryptomining, compute abuse), and in severe cases, ransomware deployments against storage services.
• Compliance Violations: Exposure of cloud identity data may trigger breach notification obligations under GDPR, HIPAA, or PCI DSS, leading to regulatory fines and reputational damage.
• Supply Chain Risk: If the Flowise instance handles multi-tenant data (e.g., an internal tool used across departments), the attacker can pivot to any connected systems.

Affected Systems:

• All Flowise deployments running version ≤ 3.1.4.
• Specifically critical for deployments on Oracle Cloud Infrastructure (OCI) or Alibaba Cloud — the two providers whose metadata endpoints are omitted.
• Deployments on AWS, Azure, or GCP also remain potentially affected via the redirect bypass, though the primary metadata IPs for those providers (169.254.169.254) are already in the deny-list; however, redirects to those IPs may still succeed if the deny-list validation does not recurse.

Blast Radius: Any cloud resource that the compromised instance's IAM role can access. This includes object storage, databases, compute snapshots, and adjacent services.

Detection Guidance

Sigma Rule

title: Flowrise SSRF Exploitation via Cloud Metadata Endpoints
id: 6f5b2c1a-9d4e-4f8a-bc2d-7e3f1a0c5b9e
status: experimental
description: Detects HTTP requests to Flowrise fetch-links endpoint targeting cloud metadata services (OCI 192.0.0.192, Alibaba 100.100.100.200) or redirect bypass attempts.
logsource:
  category: webserver
  definition: 'Requirements: Flowrise access logs or reverse proxy logs (Nginx/Apache)'
detection:
  selection_request:
    cs-uri-query|contains:
      - '/api/v1/fetch-links'
  selection_target_ip:
    cs-host|endswith:
      - '192.0.0.192'
      - '100.100.100.200'
  selection_metadata_path:
    cs-uri-query|contains:
      - '/latest/meta-data/'
      - '/opc/v2/instance/'
      - '/opc/v2/instance/bv-metadata/'
      - '/latest/meta-data/ram/security-credentials/'
  condition: selection_request and (selection_target_ip or selection_metadata_path)
  timeframe: 5m
level: high
falsepositives:
  - Legitimate use of metadata endpoints in development/test environments with misconfigured instances.
fields:
  - client_ip
  - cs-host
  - cs-uri-query
  - outcome

YARA Rule

rule Flowrise_SSRF_Metadata_Endpoint_Exfil {
    meta:
        author = "Valters IT Security Research"
        description = "Detects Flowrise SSRF attempts targeting OCI and Alibaba cloud metadata endpoints"
        cve = "CVE-2026-67620"
        date = "2026-06-15"
        tlp = "WHITE"
    strings:
        $a = "/api/v1/fetch-links" ascii wide nocase
        $b = "192.0.0.192" ascii wide
        $c = "100.100.100.200" ascii wide
        $d = "opc/v2/instance" ascii wide
        $e = "latest/meta-data" ascii wide
        $f = "security-credentials" ascii wide
    condition:
        uint16(0) == 0x0D0A and
        $a and (
            $b or $c or $d or $e or $f
        )
}

Note: This YARA rule is designed for inspecting HTTP request logs or packet captures (PCAPs). Adjust offsets if scanning raw PCAP data.

Suricata IDS Rule

alert http any any -> $HOME_NET any (msg:"CVE-2026-67620 Flowrise SSRF to Cloud Metadata Service"; flow:to_server,established; http.method; content:"GET"; http.uri; content:"/api/v1/fetch-links"; fast_pattern; http.uri; content:"url="; http.host; content:"192.0.0.192"; or content:"100.100.100.200"; or content:"opc/v2"; or content:"latest/meta-data"; classtype:attempted-information-leak; sid:670001; rev:1; metadata:created_at 2026-06-01, cve CVE-2026-67620;)

Note: This is a simplified signature. For production, consider splitting into multiple rules to handle URL encoding and alternative parameter ordering. Test against legitimate traffic to tune false positives.

Elastic Detection

sequence by host.name with maxspan=1m
  [network where event.outcome == "success" and data.stream == "http" and process.name == "node" and 
   url.original like "*fetch-links*" and 
   (destination.address == "192.0.0.192" or destination.address == "100.100.100.200" or 
    url.path like "*opc/v2/instance*" or url.path like "*latest/meta-data*")]
  [file where event.action == "read" and file.path like "*proc*" ]

Note: The above EQL is illustrative. Adjust indices to match your HTTP access log configuration (e.g., use logs-http* index pattern). In practice, you may also look for anomalous outbound requests from the Flowise server to non-standard IPs.

Splunk SPL Query

index=web sourcetype=access_combined
| where like(uri_path, "%/api/v1/fetch-links%")
| rex field=uri_query "url=(?<fetch_url>[^&]+)"
| eval fetch_url=urldecode(fetch_url)
| where like(fetch_url, "%192.0.0.192%") OR like(fetch_url, "%100.100.100.200%") OR like(fetch_url, "%opc/v2%") OR like(fetch_url, "%latest/meta-data%")
| table _time, clientip, host, uri, fetch_url, status
| sort - _time

Note: Replace index=web with your appropriate index name. For proxy logs, adjust field names accordingly (e.g., url, src_ip).

Wazuh OSSEC Rule

<group name="flowrise, ssrf,">
  <rule id="279402" level="12">
    <decoded>ossec:alert</decoded>
    <field name="url">\.*fetch-links\.*</field>
    <field name="url">(?:192\.0\.0\.192|100\.100\.100\.200|opc/v2/instance|latest/meta-data)</field>
    <description>Flowrise SSRF attempt detected - target cloud metadata endpoint</description>
    <group>attack.exploitation,</group>
    <mitre>
      <id>T1190</id>
    </mitre>
    <options>no_full_log</options>
  </rule>
</group>

Note: This rule assumes Wazuh is parsing web access logs. Ensure the appropriate decoder (e.g., Nginx, Apache) is active. Adjust field name url to uri if needed.

Mitigation & Patch Guidance

Patch Confidence: 0/4 — UNPATCHED. Flowise has not released a public fix as of the date of this report. The following mitigations are recommended in order of immediacy:

1. Immediate Mitigations:

   • Network Egress Filtering: At the firewall or egress NAT level, block outbound TCP/UDP connections to 192.0.0.192/32 and 100.100.100.200/32. Also consider blocking 169.254.169.254/32 (AWS/Azure/GCP metadata) as a defense-in-depth measure.
   • API Endpoint Restriction: If public chatflows are not strictly required, reconfigure Flowise to require authentication for all /api/v1/fetch-links requests. Disable any URL-fetching nodes in chatflows where they are not essential.
   • Reverse Proxy Rule: Add a WAF rule at the reverse proxy (Nginx/Apache) to reject requests to the fetch-links endpoint where the url parameter resolves to a deny-listed IP or contains pattern 192.0.0.192 or 100.100.100.200.
   • Redirect Disable: If feasible in the Flowise configuration, set the HTTP client to redirect: 'manual' and manually validate redirect targets.

2. Patch/Upgrade Steps:

   • Monitor the Flowise GitHub repository (https://github.com/FlowiseAI/Flowise) and official releases page for a patched version (expected ≥ 3.2.0). When a fix is released, upgrade immediately.
   • As an interim measure, apply a manual patch by editing httpSecurity.ts to add 192.0.0.192/32 and 100.100.100.200/32 to the DEFAULT_DENY_LIST array and add recursive validation for redirects. Rebuild the Docker image or Node.js bundle accordingly.

3. Long-Term Hardening:

   • Cloud IAM Best Practices: Apply the principle of least privilege to instance roles. Ensure that the role attached to the Flowrise instance does not have broad access (e.g., avoid Tenancy-wide read permissions). Use resource-level policies to limit access to specific buckets/services.
   • Metadata Service Hardening: On OCI, enable the "Instance Metadata Service v1" if available (the v2 endpoint is enabled by default, but consider disabling v1). On Alibaba Cloud, enable the "Metadata Service" with access control if your instance supports it (some instance types allow disabling the service entirely).
   • Segmentation: Run Flowrise in a separate VCN/VPC subnet with restrictive security group rules that prohibit outbound access to internal metadata network ranges.
   • Monitoring: Activate audit logging for instance metadata access in your cloud provider. Use Security Hub (OCI Cloud Guard, Alibaba Cloud Situation Awareness) to alert on unusual API calls originating from the Flowrise instance.
   • Vulnerability Management: Add Flowrise to your vulnerability scanner's software inventory and subscribe to CVE notifications to expedite patch deployment.

References

1. NVD Entry: https://nvd.nist.gov/vuln/detail/CVE-2026-67620 [Pending full analysis publication]
2. Flowise Official GitHub Repository: https://github.com/FlowiseAI/Flowise — Monitor for upstream fix commits referencing httpSecurity.ts.
3. Oracle Cloud Infrastructure Documentation — Instance Metadata Service: https://docs.oracle.com/en-us/iaas/Content/Compute/Tasks/gettingmetadata.htm (for context on the 192.0.0.192 endpoint).
4. Alibaba Cloud Instance Metadata Service: https://www.alibabacloud.com/help/en/ecs/user-guide/instance-metadata-service (for context on the 100.100.100.200 endpoint).
5. CISA Known Exploited Vulnerabilities Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog — No entry for CVE-2026-67620 as of the report date; no known in-the-wild exploitation has been reported to CISA.

Threat Actor Activity: No public exploitation campaigns or malware families have been observed leveraging CVE-2026-67620 as of the analysis date. The vulnerability is theoretical yet highly practical, given the prevalence of public chatflows and the simplicity of the exploitation chain. Security monitoring should remain vigilant as the absence of a patch increases the likelihood of weaponization by opportunistic threat actors or cloud-scanner botnets.