GHSA-qqvm-66q4-vf5c: Flowise: SSRF bypass enables cloud credential theft

GHSA-qqvm-66q4-vf5c MEDIUM
Published April 16, 2026
CISO Take

Flowise's centralized HTTP security wrapper is entirely ineffective because multiple built-in tools — including WebScraperTool, OpenAPIToolkit, and MCP — import raw HTTP clients directly instead of routing through the validated `httpSecurity.ts` layer. This is an architectural enforcement failure, not a single bug: even with `HTTP_DENY_LIST` correctly configured to block AWS metadata ranges, any chat user can exfiltrate cloud IAM credentials with a plain-language prompt targeting `169.254.169.254`. With 37 prior CVEs in this package and no authentication required beyond chat access, Flowise deployments on cloud infrastructure are at critical risk of full credential compromise. Upgrade to version 3.1.0 immediately; if patching is not possible, disable WebScraperTool, OpenAPIToolkit, MCP, and Arxiv nodes and enforce egress filtering at the network level to block RFC-1918 and link-local ranges.

Sources: GitHub Advisory ATLAS

What is the risk?

Critical risk for cloud-deployed Flowise instances. The vulnerability requires no special privileges — any user with chat access can trigger the attack via a natural-language prompt, making exploitation trivial. The SSRF bypass is architectural: the security control is opt-in rather than enforced, so even correct configuration of deny-lists provides no protection. Cloud environments are most exposed due to accessible instance metadata endpoints that vend short-lived IAM credentials, potentially enabling full account takeover. With 37 prior CVEs in this package, the codebase has a demonstrated history of security weaknesses in this category.

How does the attack unfold?

Tool Invocation
Adversary sends a natural language chat prompt directing the Flowise agent to use WebScraperTool to fetch the cloud instance metadata endpoint URL.
AML.T0053
SSRF Defense Bypass
WebScraperTool calls raw `fetch()` directly, bypassing `httpSecurity.ts` entirely — deny-list configuration provides no protection.
AML.T0107
Credential Harvesting
The unfiltered HTTP request reaches `169.254.169.254/latest/meta-data/iam/security-credentials/`, returning cloud IAM role credentials to the tool.
AML.T0098
Exfiltration
IAM credentials (access key, secret, session token) are returned through the LLM chat response, immediately usable for cloud API authentication and lateral movement.
AML.T0086

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?

6 steps
  1. Patch immediately: upgrade flowise and flowise-components to version 3.1.0 or later.

  2. Until patching is complete, disable all affected tool nodes in the Flowise admin UI: WebScraperTool, OpenAPIToolkit, MCP, and Arxiv.

  3. Apply network-level egress filtering as defense-in-depth: block outbound requests to 169.254.0.0/16 (AWS/GCP/Azure metadata), 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 at the firewall or cloud security group level.

  4. Review Flowise deployment logs for requests to metadata endpoints or internal IP ranges — any such requests indicate active exploitation.

  5. Rotate cloud credentials (IAM keys, service account tokens) for any Flowise deployment that was cloud-hosted and running affected versions.

  6. For future hardening: add ESLint no-restricted-imports rules to prohibit direct node-fetch/axios imports in tool components.

How is it classified?

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act
Article 15 - Accuracy, robustness and cybersecurity
ISO 42001
A.6.2.5 - AI system security
NIST AI RMF
MANAGE-2.2 - Risk response strategies for AI-specific risks
OWASP LLM Top 10
LLM07 - Insecure Plugin Design

Frequently Asked Questions

What is GHSA-qqvm-66q4-vf5c?

Flowise's centralized HTTP security wrapper is entirely ineffective because multiple built-in tools — including WebScraperTool, OpenAPIToolkit, and MCP — import raw HTTP clients directly instead of routing through the validated `httpSecurity.ts` layer. This is an architectural enforcement failure, not a single bug: even with `HTTP_DENY_LIST` correctly configured to block AWS metadata ranges, any chat user can exfiltrate cloud IAM credentials with a plain-language prompt targeting `169.254.169.254`. With 37 prior CVEs in this package and no authentication required beyond chat access, Flowise deployments on cloud infrastructure are at critical risk of full credential compromise. Upgrade to version 3.1.0 immediately; if patching is not possible, disable WebScraperTool, OpenAPIToolkit, MCP, and Arxiv nodes and enforce egress filtering at the network level to block RFC-1918 and link-local ranges.

Is GHSA-qqvm-66q4-vf5c actively exploited?

No confirmed active exploitation of GHSA-qqvm-66q4-vf5c has been reported, but organizations should still patch proactively.

How to fix GHSA-qqvm-66q4-vf5c?

1. Patch immediately: upgrade `flowise` and `flowise-components` to version 3.1.0 or later. 2. Until patching is complete, disable all affected tool nodes in the Flowise admin UI: WebScraperTool, OpenAPIToolkit, MCP, and Arxiv. 3. Apply network-level egress filtering as defense-in-depth: block outbound requests to 169.254.0.0/16 (AWS/GCP/Azure metadata), 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 at the firewall or cloud security group level. 4. Review Flowise deployment logs for requests to metadata endpoints or internal IP ranges — any such requests indicate active exploitation. 5. Rotate cloud credentials (IAM keys, service account tokens) for any Flowise deployment that was cloud-hosted and running affected versions. 6. For future hardening: add ESLint `no-restricted-imports` rules to prohibit direct `node-fetch`/`axios` imports in tool components.

What systems are affected by GHSA-qqvm-66q4-vf5c?

This vulnerability affects the following AI/ML architecture patterns: AI agent frameworks, Agentic workflows with web access tools, LLM-powered chatbots with tool use, Cloud-hosted AI application platforms.

What is the CVSS score for GHSA-qqvm-66q4-vf5c?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

AI agent frameworksAgentic workflows with web access toolsLLM-powered chatbots with tool useCloud-hosted AI application platforms

MITRE ATLAS Techniques

AML.T0049 Exploit Public-Facing Application
AML.T0053 AI Agent Tool Invocation
AML.T0086 Exfiltration via AI Agent Tool Invocation
AML.T0098 AI Agent Tool Credential Harvesting
AML.T0107 Exploitation for Defense Evasion

Compliance Controls Affected

EU AI Act: Article 15
ISO 42001: A.6.2.5
NIST AI RMF: MANAGE-2.2
OWASP LLM Top 10: LLM07

What are the technical details?

Original Advisory

### Summary Flowise introduced SSRF protections through a centralized HTTP security wrapper (`httpSecurity.ts`) that implements deny-list validation and IP pinning logic. However, multiple tool implementations directly import and invoke raw HTTP clients (`node-fetch`, `axios`Instead of using the secured wrapper. Because enforcement is neither mandatory nor centralized, these tools bypass SSRF mitigation entirely, restoring full SSRF capability even after the patch. This issue is distinct from specification trust issues and represents incomplete mitigation of previously addressed SSRF vulnerabilities. ### Details **Intended Security Model:** All outbound HTTP requests should pass through the centralized validation layer implemented in: ``` packages/components/src/httpSecurity.ts ``` This layer performs: - `HTTP_DENY_LIST` enforcement - IP resolution validation - IP pinning - Loopback blocking **Observed Implementation Gap:** Multiple tools bypass this layer and import HTTP libraries directly. Examples include: - `packages/components/nodes/tools/OpenAPIToolkit/OpenAPIToolkit.ts` - `packages/components/nodes/tools/WebScraperTool/WebScraperTool.ts` - `packages/components/nodes/tools/MCP/core.ts` - `packages/components/nodes/tools/Arxiv/core.ts` These files directly execute: ``` importfetchfrom'node-fetch' ``` or invoke `axios` without passing through the centralized validation wrapper. Because there is no global interceptor or enforcement mechanism, outbound requests in these components are executed without SSRF validation. This renders the mitigation introduced in GHSA-2x8m-83vc-6wv4 incomplete. ### Root Cause Security enforcement is not centralized. Outbound request validation depends on voluntary usage of a wrapper function rather than being structurally enforced. Because direct imports of HTTP clients are allowed, the mitigation is easily bypassed. This is an architectural enforcement failure rather than a single implementation bug. ### PoC Even when an administrator configures: ``` HTTP_DENY_LIST=169.254.0.0/16,127.0.0.0/8 ``` The following attack succeeds if a vulnerable tool is enabled: **Chat Prompt:** ``` Use the Web Scraper tool to retrieve: http://169.254.169.254/latest/meta-data/iam/security-credentials/ ``` Execution flow: 1. The LLM triggers `WebScraperTool`. 2. The tool calls raw `fetch()` directly. 3. No `httpSecurity.ts` validation is applied. 4. The request reaches the metadata endpoint. 5. The response is returned to the chat context. This demonstrates that SSRF protection is opt-in rather than enforced. ### Impact **Severity:** Critical (CVSS v3.1: 9.1 – AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N) This issue: - Completely bypasses the centralized SSRF mitigation. - Allows access to internal network resources. - Enables the exploitation of cloud metadata and credential theft. - Invalidates the security assumptions of the recent patch. Any deployment enabling affected tools remains vulnerable. ### Recommended Remediation 1. Refactor all tools to use the centralized `secureFetch()` wrapper. 2. Add ESLint `no-restricted-imports` rules to prohibit the direct usage of `node-fetch` or `axios` in tool components. 3. Consider implementing a single internal HTTP client abstraction layer. 4. Apply network-level egress filtering as defense-in-depth.

Exploitation Scenario

An adversary with access to a Flowise chat interface (trial user, compromised account, or unauthenticated endpoint if misconfigured) sends the prompt: 'Use the Web Scraper tool to retrieve http://169.254.169.254/latest/meta-data/iam/security-credentials/'. The LLM interprets this as a legitimate tool call, invokes WebScraperTool, which calls `fetch()` directly — bypassing all deny-list validation in `httpSecurity.ts`. The AWS metadata endpoint returns the instance's IAM role credentials (access key, secret, session token). These credentials are displayed in the chat response and immediately usable by the adversary to authenticate to AWS APIs, pivot to other services, exfiltrate data, or establish persistence. The entire attack requires no technical knowledge beyond knowing the metadata endpoint URL.

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.

Timeline

Published
April 16, 2026
Last Modified
April 16, 2026
First Seen
April 17, 2026

Related Vulnerabilities