CVE-2026-56275: Flowise: SSRF bypasses security check in Execute Flow

UNKNOWN

Published June 23, 2026

CISO Take

Flowise's Execute Flow node fails to invoke secureFetch validation when processing the base URL field, allowing any user with flow-editing access to route HTTP requests through the Flowise server to internal network addresses and cloud instance metadata endpoints. In cloud-deployed environments—the default for most enterprise Flowise installations—this converts a medium-severity SSRF into a credential theft vector: a single malicious flow execution against 169.254.169.254 on AWS can return IAM role credentials, enabling full cloud account takeover. Flowise has accumulated 100 CVEs in this same package, signaling a pattern of systemic security debt that elevates the likelihood of chained exploitation. Upgrade to Flowise 3.1.0 immediately; enforce IMDSv2 on all cloud instances hosting Flowise and block egress to RFC 1918 ranges and metadata endpoints as a compensating control pending upgrade.

Sources:NVDGitHub AdvisoryVulnCheckATLAS

What is the risk?

Despite the medium CVSS designation (reflecting no current public exploit or KEV listing), operational risk is elevated in cloud-hosted deployments where IMDS access is available by default. Exploitation requires only flow-editor access—a permission commonly granted broadly in collaborative Flowise environments—and the technique is trivially executable with no specialized tooling. The 100-CVE history in the same package suggests inadequate security investment at the framework level, increasing compound risk from chained vulnerabilities. On-premises deployments face internal service enumeration risk rather than credential theft, but both scenarios enable lateral movement beyond the AI workload perimeter.

How does the attack unfold?

Initial Access

Attacker gains access to the Flowise flow editor via exposed public instance, stolen credentials, or overly permissive access controls on a shared deployment.

AML.T0049

SSRF Configuration

Attacker creates or modifies an Execute Flow node setting the base URL to an internal address (e.g., 169.254.169.254 or RFC 1918 range), exploiting the absent secureFetch validation in httpSecurity.ts.

AML.T0053

Internal Discovery

Flow execution triggers server-side HTTP requests to internal targets, enumerating cloud metadata endpoints, internal APIs, admin panels, and database services visible from the Flowise host.

AML.T0075

Credential Theft

Attacker retrieves cloud IAM credentials or internal service tokens from SSRF responses and uses them externally for lateral movement or full cloud account takeover beyond the Flowise deployment.

AML.T0106

Initial Access

Attacker gains access to the Flowise flow editor via exposed public instance, stolen credentials, or overly permissive access controls on a shared deployment.

AML.T0049

SSRF Configuration

AML.T0053

Internal Discovery

Flow execution triggers server-side HTTP requests to internal targets, enumerating cloud metadata endpoints, internal APIs, admin panels, and database services visible from the Flowise host.

AML.T0075

Credential Theft

Attacker retrieves cloud IAM credentials or internal service tokens from SSRF responses and uses them externally for lateral movement or full cloud account takeover beyond the Flowise deployment.

AML.T0106

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

N/A

EPSS

0.3%

chance of exploitation in 30 days

Higher than 24% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Trivial

What should I do?

5 steps

Upgrade to Flowise 3.1.0 or later, which patches the missing secureFetch call in httpSecurity.ts.
Enforce IMDSv2 (session-oriented) on all EC2/GCP/Azure instances hosting Flowise—this requires a session token header that SSRF cannot supply, blocking metadata credential theft.
Apply host-level or network-level egress firewall rules blocking outbound HTTP from the Flowise process to 169.254.169.254, fd00:ec2::254, and RFC 1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) except explicitly required internal endpoints.
Restrict flow-editing permissions to a minimal set of trusted users—treat this as equivalent to code execution permissions.
Enable and monitor outbound HTTP logs from the Flowise container or host; alert on any connections to private IP ranges or link-local addresses as a detection signal.

What does CISA's SSVC say?

DecisionTrack

Exploitationnone

AutomatableNo

Technical Impactpartial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Data ExtractionAuth BypassAgentFrameworkAML.T0006- Active Scanning AML.T0049- Exploit Public-Facing Application AML.T0053- AI Agent Tool Invocation AML.T0075- Cloud Service Discovery

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Art. 9-Risk Management System

ISO 42001

A.6.2.3-AI system security

NIST AI RMF

MANAGE 2.4-Mechanisms are in place for AI system maintenance and improvement

OWASP LLM Top 10

LLM07-Insecure Plugin Design

Frequently Asked Questions

What is CVE-2026-56275?

Is CVE-2026-56275 actively exploited?

No confirmed active exploitation of CVE-2026-56275 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-56275?

1. Upgrade to Flowise 3.1.0 or later, which patches the missing secureFetch call in httpSecurity.ts. 2. Enforce IMDSv2 (session-oriented) on all EC2/GCP/Azure instances hosting Flowise—this requires a session token header that SSRF cannot supply, blocking metadata credential theft. 3. Apply host-level or network-level egress firewall rules blocking outbound HTTP from the Flowise process to 169.254.169.254, fd00:ec2::254, and RFC 1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) except explicitly required internal endpoints. 4. Restrict flow-editing permissions to a minimal set of trusted users—treat this as equivalent to code execution permissions. 5. Enable and monitor outbound HTTP logs from the Flowise container or host; alert on any connections to private IP ranges or link-local addresses as a detection signal.

What systems are affected by CVE-2026-56275?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, no-code AI builders, LLM orchestration pipelines, cloud-hosted AI deployments.

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

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

agent frameworksno-code AI buildersLLM orchestration pipelinescloud-hosted AI deployments

MITRE ATLAS Techniques

AML.T0006Active Scanning

AML.T0049Exploit Public-Facing Application

AML.T0053AI Agent Tool Invocation

AML.T0075Cloud Service Discovery

Compliance Controls Affected

EU AI Act: Art. 9

ISO 42001: A.6.2.3

NIST AI RMF: MANAGE 2.4

OWASP LLM Top 10: LLM07

What are the technical details?

Original Advisory

Flowise before 3.1.0 contains a server-side request forgery vulnerability in the Execute Flow node that allows attackers to bypass security validation by providing intranet addresses through the base URL field. Attackers can initiate HTTP requests to internal network addresses, access cloud metadata, and enumerate internal services by exploiting the missing secureFetch verification in httpSecurity.ts.

Exploitation Scenario

An attacker with Flowise UI access—obtained via compromised credentials, a misconfigured public-facing Flowise instance, or insider access—creates a new flow containing an Execute Flow node with base URL set to http://169.254.169.254/latest/meta-data/iam/security-credentials/. When the flow runs, Flowise's httpSecurity.ts skips the secureFetch guard and issues the HTTP GET server-side. The metadata service returns the attached IAM role name; the attacker follows up with a second request to /latest/meta-data/iam/security-credentials/<role-name> and retrieves valid AWS access keys, secret keys, and session tokens. These credentials are used externally to authenticate to the AWS API and escalate privileges across the cloud environment, entirely through the AI workflow interface.

Weaknesses (CWE)

CWE-918Server-Side Request Forgery CWE-918Server-Side Request Forgery

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

[Implementation, Operation] If there is a known list of applications, IP, hostname, and/or domains to which the product is allowed to communicate, then use allowlists to ensure that outgoing requests are restricted to these known entities. The allowlists could be in the application code or possibly enforced by firewalls or network segmentation [REF-1511].
[Implementation, Operation] If the product is expected to be able to connect to arbitrary IP addresses or domains, consider using a denylist that includes private network addresses, internal domain names, etc. The denylist could be in the application code or possibly enforced by firewalls or network segmentation [REF-1511].

Source: MITRE CWE corpus.