GHSA-9hrv-gvrv-6gf2: Flowise SSRF bypass enables

Q: Is GHSA-9hrv-gvrv-6gf2 actively exploited?

No confirmed active exploitation of GHSA-9hrv-gvrv-6gf2 has been reported, but organizations should still patch proactively.

Q: How to fix GHSA-9hrv-gvrv-6gf2?

1. Patch immediately: upgrade both flowise and flowise-components to 3.1.0, which applies secureFetch validation to the Execute Flow node base URL. 2. Emergency network controls if patching is delayed: block outbound HTTP/HTTPS from the Flowise process to 169.254.169.254 (AWS/GCP IMDS), 100.100.100.200 (Alibaba Cloud IMDS), fd00:ec2::254 (AWS IPv6 IMDS), and all RFC 1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). 3. Audit all Execute Flow node configurations in existing workflows for user-supplied or externally controlled base URL values. 4. Review egress logs for anomalous HTTP requests to internal or metadata endpoints originating from the Flowise process. 5. Rotate cloud IAM credentials assigned to the Flowise host if exploitation cannot be ruled out, and review CloudTrail/audit logs for unexpected API calls from the instance role.

Q: What systems are affected by GHSA-9hrv-gvrv-6gf2?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, LLM workflow orchestration, cloud-hosted AI pipelines, multi-tenant AI platforms, self-hosted AI automation.

Q: What is the CVSS score for GHSA-9hrv-gvrv-6gf2?

No CVSS score has been assigned yet.

CISO Take

Flowise's Execute Flow node allows any authenticated user to supply an arbitrary internal URL as the base URL field, entirely bypassing the platform's deny-list validation because httpSecurity.ts is never invoked in this code path. In cloud-hosted environments — where most enterprise AI agent deployments live — this translates directly to cloud instance metadata service (IMDS) access at 169.254.169.254, enabling IAM credential theft and privilege escalation with a trivially simple HTTP request. With 37 historical CVEs in the Flowise package, this is part of a pattern of security gaps in a widely-used AI orchestration platform; no EPSS data is available yet, but the attack requires only authenticated access to execute. Upgrade both flowise and flowise-components to 3.1.0 immediately, and if patching is delayed, block all egress from the Flowise host to RFC 1918 ranges and cloud IMDS endpoints.

Sources: GitHub Advisory ATLAS

What is the risk?

Medium by CVSS but operationally high-impact in cloud and enterprise environments. SSRF in AI agent orchestration platforms is especially dangerous because these systems typically run with elevated network access — directly connected to internal APIs, model endpoints, databases, and cloud services. The bypass of an existing security control (rather than the absence of one) suggests the deny-list was added reactively and its coverage is incomplete. Flowise's 37-CVE history signals a systemic pattern of insufficient security hardening across the codebase.

How does the attack unfold?

Initial Access

Attacker authenticates to a Flowise instance using legitimate credentials, a shared API key, or a compromised account in a multi-tenant deployment.

AML.T0012

Security Control Bypass

Attacker configures the Execute Flow node's base URL field with an internal or cloud metadata address; the deny-list check in httpSecurity.ts is never invoked for this code path.

AML.T0049

Internal Reconnaissance

Flowise server issues an HTTP request to the attacker-controlled internal URL (e.g., cloud IMDS at 169.254.169.254 or an internal admin panel), and the full HTTP response is echoed back to the attacker.

AML.T0075

Credential Theft & Lateral Movement

Attacker harvests cloud IAM credentials or internal API tokens from the SSRF response, enabling lateral movement to cloud storage, databases, and other internal services.

AML.T0055

Initial Access

Attacker authenticates to a Flowise instance using legitimate credentials, a shared API key, or a compromised account in a multi-tenant deployment.

AML.T0012

Security Control Bypass

Attacker configures the Execute Flow node's base URL field with an internal or cloud metadata address; the deny-list check in httpSecurity.ts is never invoked for this code path.

AML.T0049

Internal Reconnaissance

Flowise server issues an HTTP request to the attacker-controlled internal URL (e.g., cloud IMDS at 169.254.169.254 or an internal admin panel), and the full HTTP response is echoed back to the attacker.

AML.T0075

Credential Theft & Lateral Movement

Attacker harvests cloud IAM credentials or internal API tokens from the SSRF response, enabling lateral movement to cloud storage, databases, and other internal services.

AML.T0055

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Flowise	npm	<= 3.0.13	`3.1.0`
Flowise	npm	<= 3.0.13	`3.1.0`

How severe is it?

CVSS 3.1

N/A

EPSS

N/A

Exploitation Status

No known exploitation

Sophistication

Trivial

What should I do?

5 steps

Patch immediately: upgrade both flowise and flowise-components to 3.1.0, which applies secureFetch validation to the Execute Flow node base URL.
Emergency network controls if patching is delayed: block outbound HTTP/HTTPS from the Flowise process to 169.254.169.254 (AWS/GCP IMDS), 100.100.100.200 (Alibaba Cloud IMDS), fd00:ec2::254 (AWS IPv6 IMDS), and all RFC 1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16).
Audit all Execute Flow node configurations in existing workflows for user-supplied or externally controlled base URL values.
Review egress logs for anomalous HTTP requests to internal or metadata endpoints originating from the Flowise process.
Rotate cloud IAM credentials assigned to the Flowise host if exploitation cannot be ruled out, and review CloudTrail/audit logs for unexpected API calls from the instance role.

How is it classified?

Data Extraction Auth Bypass Privacy Violation Agent Framework AML.T0049 - Exploit Public-Facing Application AML.T0053 - AI Agent Tool Invocation AML.T0055 - Unsecured Credentials AML.T0075 - Cloud Service Discovery

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, Robustness and Cybersecurity

ISO 42001

A.6.1 - AI System Risk Management

NIST AI RMF

MANAGE-2.2 - Risk Treatment

OWASP LLM Top 10

LLM02 - Sensitive Information Disclosure LLM06 - Excessive Agency

Frequently Asked Questions

What is GHSA-9hrv-gvrv-6gf2?

Flowise's Execute Flow node allows any authenticated user to supply an arbitrary internal URL as the base URL field, entirely bypassing the platform's deny-list validation because httpSecurity.ts is never invoked in this code path. In cloud-hosted environments — where most enterprise AI agent deployments live — this translates directly to cloud instance metadata service (IMDS) access at 169.254.169.254, enabling IAM credential theft and privilege escalation with a trivially simple HTTP request. With 37 historical CVEs in the Flowise package, this is part of a pattern of security gaps in a widely-used AI orchestration platform; no EPSS data is available yet, but the attack requires only authenticated access to execute. Upgrade both flowise and flowise-components to 3.1.0 immediately, and if patching is delayed, block all egress from the Flowise host to RFC 1918 ranges and cloud IMDS endpoints.

Is GHSA-9hrv-gvrv-6gf2 actively exploited?

No confirmed active exploitation of GHSA-9hrv-gvrv-6gf2 has been reported, but organizations should still patch proactively.

How to fix GHSA-9hrv-gvrv-6gf2?

1. Patch immediately: upgrade both flowise and flowise-components to 3.1.0, which applies secureFetch validation to the Execute Flow node base URL. 2. Emergency network controls if patching is delayed: block outbound HTTP/HTTPS from the Flowise process to 169.254.169.254 (AWS/GCP IMDS), 100.100.100.200 (Alibaba Cloud IMDS), fd00:ec2::254 (AWS IPv6 IMDS), and all RFC 1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). 3. Audit all Execute Flow node configurations in existing workflows for user-supplied or externally controlled base URL values. 4. Review egress logs for anomalous HTTP requests to internal or metadata endpoints originating from the Flowise process. 5. Rotate cloud IAM credentials assigned to the Flowise host if exploitation cannot be ruled out, and review CloudTrail/audit logs for unexpected API calls from the instance role.

What systems are affected by GHSA-9hrv-gvrv-6gf2?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, LLM workflow orchestration, cloud-hosted AI pipelines, multi-tenant AI platforms, self-hosted AI automation.

What is the CVSS score for GHSA-9hrv-gvrv-6gf2?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

agent frameworksLLM workflow orchestrationcloud-hosted AI pipelinesmulti-tenant AI platformsself-hosted AI automation

MITRE ATLAS Techniques

AML.T0049 Exploit Public-Facing Application

AML.T0053 AI Agent Tool Invocation

AML.T0055 Unsecured Credentials

AML.T0075 Cloud Service Discovery

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.6.1

NIST AI RMF: MANAGE-2.2

OWASP LLM Top 10: LLM02, LLM06

What are the technical details?

Original Advisory

### Summary The attacker provides an intranet address through the base url field configured in the Execute Flow node → Bypass checkDenyList / resolveAndValidate in httpSecurity.ts (not called) → Causes the server to initiate an HTTP request to any internal network address, read cloud metadata, or detect internal network services ### Details <img width="1280" height="860" alt="9a52a74e6fe2fd78e4962d1d68057fc2" src="https://github.com/user-attachments/assets/20df0006-9129-4886-8928-16d19a617c23" /> Then initiate the call: ``` POST /api/v1/prediction/d6739838-d3b3-43d9-86ff-911a3d757a7e HTTP/1.1 Host: 127.0.0.1:3000 Content-Type: application/json Authorization: Bearer apikey Content-Length: 17 {"question": "1"} ``` Server received a request: <img width="1432" height="172" alt="f45c757fec408e13739db068252ff21b" src="https://github.com/user-attachments/assets/d3dfe0f5-83ec-4c79-ab32-754382a68d5f" /> And there is an echo: <img width="1280" height="666" alt="fa0caf0deb306cfeeea8fdf8941a287e" src="https://github.com/user-attachments/assets/55a94d25-120b-4e9c-9517-46c2fc2b667f" /> Fix: Call secureFetch for verification ### Impact This is a Server-Side Request Forgery (SSRF) vulnerability that may lead to the following risks: - Explore Internal Web Applications - Access sensitive management interfaces - Leak internal configuration, credentials, or confidential information This vulnerability significantly increases the risk of internal service enumeration and potential lateral movement in enterprise environments.

Exploitation Scenario

An attacker with authenticated access to a Flowise instance — obtained via compromised credentials, a leaked API key, or a multi-tenant deployment — edits an Execute Flow node's base URL field to http://169.254.169.254/latest/meta-data/iam/security-credentials/. When the flow is triggered via POST /api/v1/prediction/{flow-id}, the Flowise server issues an outbound HTTP GET to the IMDS endpoint without invoking the checkDenyList or resolveAndValidate functions in httpSecurity.ts. The cloud provider's metadata service responds with the temporary IAM credentials of the Flowise host's attached role, which are echoed back in the prediction response. The attacker now holds valid cloud credentials — potentially with broad permissions to S3, RDS, Lambda, and other services — enabling lateral movement throughout the cloud environment. The entire attack requires a single API call after initial access.

Weaknesses (CWE)

CWE-918 Server-Side Request Forgery (SSRF) Primary

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.