CVE-2026-67620: Flowise: SSRF bypass exposes cloud metadata credentials

HIGH PoC AVAILABLE
Published August 8, 2026
CISO Take

Flowise's SSRF guard (httpSecurity.ts) ships with an incomplete deny-list that omits Oracle Cloud Infrastructure's metadata endpoint (192.0.0.192) and Alibaba Cloud's (100.100.100.200), so a crafted request to the fetch-links API — including via redirect-based bypasses — can pull instance identity data and IAM role credentials straight off the underlying cloud instance. This sits in the top 64th percentile of EPSS for near-term exploitation likelihood, and a working PoC is already public on GitHub, which materially lowers the bar for opportunistic scanning even though it isn't yet in CISA KEV. The real sting for CISOs: if any URL-fetching node exists in a public-facing chatflow, exploitation requires zero authentication, turning an exposed low-code AI agent builder into a direct pivot into your OCI or Alibaba Cloud account. Flowise itself appears to be winding down (see the vendor's own /sunset notice), so don't count on an upstream deny-list fix — remediate at the network layer instead. Enforce IMDSv2-only / metadata hop-limit controls, block egress from Flowise hosts to 192.0.0.192 and 100.100.100.200, and audit every public chatflow for URL-fetching nodes today.

Sources: NVD EPSS vulncheck.com flowiseai.com ATLAS

What is the risk?

High practical risk despite a 'high' (not critical) CVSS of 7.7: the deny-list gap is trivial to identify (public PoC), requires only low privileges in the authenticated path, and requires none at all when a URL-fetching node is exposed in a public chatflow. Impact is confidentiality-only per the vector (C:H/I:N/A:N), but the confidentiality loss is specifically cloud IAM credentials — which routinely enables follow-on privilege escalation far beyond the Flowise instance itself. Not in CISA KEV and EPSS absolute probability is low (0.4%), but the relative percentile (top 64%) plus PoC availability argue against deprioritizing this as theoretical.

How does the attack unfold?

Initial access
Attacker submits a crafted URL to Flowise's fetch-links API, requiring only low privileges — or none at all if a URL-fetching node exists in a public chatflow.
AML.T0049
SSRF guard bypass
The crafted URL (including via redirect) evades the incomplete DEFAULT_DENY_LIST, which omits the OCI and Alibaba Cloud metadata IPs.
AML.T0053
Credential harvesting
The Flowise server issues the GET request to the cloud instance metadata service and returns instance identity data and IAM role credentials to the attacker.
AML.T0055
Cloud account compromise
Attacker uses the stolen instance-role credentials as valid cloud account credentials to move laterally within the OCI or Alibaba Cloud environment.
AML.T0012

What systems are affected?

Package Ecosystem Vulnerable Range Patched
Flowise npm No patch

Do you use Flowise? You're affected.

How severe is it?

CVSS 3.1
7.7 / 10
EPSS
0.3%
chance of exploitation in 30 days
Higher than 25% of all CVEs
Exploitation Status
Exploit Available
Exploitation: MEDIUM
Sophistication
Moderate
Exploitation Confidence
medium
Public PoC indexed (trickest/cve)
Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AV AC PR UI S C I A
AV Network
AC Low
PR Low
UI None
S Changed
C High
I None
A None

What should I do?

1 step
  1. 1) Check Flowise version and confirm exposure — any URL-fetching/fetch-links node reachable via API or a public chatflow is at risk. 2) Because Flowise is reportedly sunsetting (flowiseai.com/sunset), do not wait on a vendor patch — apply network-layer controls: enforce IMDSv2 with a hop-limit of 1 on OCI/Alibaba instances hosting Flowise, and add egress firewall/security-group rules blocking outbound traffic to 192.0.0.192 and 100.100.100.200 from Flowise hosts. 3) Audit all chatflows for URL-fetching nodes exposed without authentication and disable or gate them. 4) Rotate any IAM/instance-role credentials that may have been reachable from the affected host. 5) Detection: monitor outbound requests from Flowise hosts to metadata IP ranges and flag any fetch-links API calls targeting non-allowlisted internal/link-local addresses. 6) Longer-term: evaluate migrating off Flowise given its sunset status.

How is it classified?

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act
Article 15 - Accuracy, robustness and cybersecurity
NIST AI RMF
MANAGE-4.1 - Risk treatment and monitoring for deployed AI system components
OWASP LLM Top 10
LLM06:2025 - Excessive Agency

Frequently Asked Questions

What is CVE-2026-67620?

Flowise's SSRF guard (httpSecurity.ts) ships with an incomplete deny-list that omits Oracle Cloud Infrastructure's metadata endpoint (192.0.0.192) and Alibaba Cloud's (100.100.100.200), so a crafted request to the fetch-links API — including via redirect-based bypasses — can pull instance identity data and IAM role credentials straight off the underlying cloud instance. This sits in the top 64th percentile of EPSS for near-term exploitation likelihood, and a working PoC is already public on GitHub, which materially lowers the bar for opportunistic scanning even though it isn't yet in CISA KEV. The real sting for CISOs: if any URL-fetching node exists in a public-facing chatflow, exploitation requires zero authentication, turning an exposed low-code AI agent builder into a direct pivot into your OCI or Alibaba Cloud account. Flowise itself appears to be winding down (see the vendor's own /sunset notice), so don't count on an upstream deny-list fix — remediate at the network layer instead. Enforce IMDSv2-only / metadata hop-limit controls, block egress from Flowise hosts to 192.0.0.192 and 100.100.100.200, and audit every public chatflow for URL-fetching nodes today.

Is CVE-2026-67620 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2026-67620, increasing the risk of exploitation.

How to fix CVE-2026-67620?

1) Check Flowise version and confirm exposure — any URL-fetching/fetch-links node reachable via API or a public chatflow is at risk. 2) Because Flowise is reportedly sunsetting (flowiseai.com/sunset), do not wait on a vendor patch — apply network-layer controls: enforce IMDSv2 with a hop-limit of 1 on OCI/Alibaba instances hosting Flowise, and add egress firewall/security-group rules blocking outbound traffic to 192.0.0.192 and 100.100.100.200 from Flowise hosts. 3) Audit all chatflows for URL-fetching nodes exposed without authentication and disable or gate them. 4) Rotate any IAM/instance-role credentials that may have been reachable from the affected host. 5) Detection: monitor outbound requests from Flowise hosts to metadata IP ranges and flag any fetch-links API calls targeting non-allowlisted internal/link-local addresses. 6) Longer-term: evaluate migrating off Flowise given its sunset status.

What systems are affected by CVE-2026-67620?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, low-code AI orchestration platforms, public-facing chatbot deployments.

What is the CVSS score for CVE-2026-67620?

CVE-2026-67620 has a CVSS v3.1 base score of 7.7 (HIGH). The EPSS exploitation probability is 0.32%.

What is the AI security impact?

Affected AI Architectures

agent frameworkslow-code AI orchestration platformspublic-facing chatbot deployments

MITRE ATLAS Techniques

AML.T0049 Exploit Public-Facing Application
AML.T0053 AI Agent Tool Invocation
AML.T0055 Unsecured Credentials

Compliance Controls Affected

EU AI Act: Article 15
NIST AI RMF: MANAGE-4.1
OWASP LLM Top 10: LLM06:2025

What are the technical details?

Original Advisory

Flowise through 3.1.4 contains a server-side request forgery vulnerability in the SSRF guard implemented in httpSecurity.ts, where the DEFAULT_DENY_LIST omits the Oracle Cloud Infrastructure metadata endpoint 192.0.0.192 and the Alibaba Cloud metadata endpoint 100.100.100.200, allowing authenticated attackers to force the server to issue arbitrary GET requests to cloud instance metadata services. Attackers can send requests to the fetch-links API endpoint with a crafted URL parameter, bypassing deny-list validation including redirect-based bypasses, to reach instance metadata services and expose instance identity data and role credentials on Oracle Cloud Infrastructure or Alibaba Cloud deployments, with unauthenticated access possible when URL-fetching nodes exist in public chatflows.

Exploitation Scenario

An attacker interacting with a Flowise instance — either as a low-privilege authenticated user, or completely unauthenticated if a URL-fetching node is wired into a public chatflow — submits a crafted URL parameter to the fetch-links API targeting 192.0.0.192 (OCI) or 100.100.100.200 (Alibaba Cloud), optionally using a redirect chain to slip past the deny-list validation. The Flowise server, running on the victim's cloud instance, issues the GET request on the attacker's behalf and returns the instance metadata response — including identity data and temporary IAM role credentials — back through the chatflow response. The attacker then uses those stolen cloud credentials to enumerate and access other resources in the OCI or Alibaba Cloud account, turning an application-layer SSRF into full cloud infrastructure compromise.

Weaknesses (CWE)

CWE-918 — Server-Side Request Forgery (SSRF): 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.

Source: MITRE CWE corpus.

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N

Timeline

Published
August 8, 2026
Last Modified
September 4, 2026
First Seen
August 8, 2026

Related Vulnerabilities