CVE-2026-41272: Flowise SSRF bypass — HIGH

Q: Is CVE-2026-41272 actively exploited?

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

Q: How to fix CVE-2026-41272?

1. PATCH: Upgrade Flowise to 3.1.0 or later—this is the only complete remediation. 2. NETWORK ISOLATION: Restrict Flowise outbound traffic via security groups or firewall rules; block RFC 1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) and cloud metadata IPs (169.254.169.254, fd00:ec2::254) at the network layer regardless of patch status. 3. CLOUD HARDENING: Enable IMDSv2 on all AWS EC2 instances to require session tokens, neutralizing metadata SSRF impact even if exploitation occurs. 4. DENY LIST AUDIT: Verify that Flowise deny lists are explicitly configured and not relying on defaults; treat any Flowise instance running pre-3.1.0 with default config as fully SSRF-exposed. 5. DETECTION: Monitor Flowise HTTP logs for requests to internal IP ranges or metadata service addresses; alert on DNS responses with very short TTLs (<5 seconds) originating from Flowise processes.

Q: What systems are affected by CVE-2026-41272?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, LLM workflow orchestration, cloud-hosted AI applications, internal API integrations.

Q: What is the CVSS score for CVE-2026-41272?

CVE-2026-41272 has a CVSS v3.1 base score of 7.1 (HIGH). The EPSS exploitation probability is 0.26%.

CISO Take

Flowise's HTTP security wrappers—specifically designed to block SSRF—can be defeated through DNS rebinding (a Time-of-Check Time-of-Use race against the allow-list resolver) or, more trivially, by targeting the default configuration which enforces no deny list whatsoever. This is a direct threat to any enterprise running Flowise in cloud environments: SSRF is the canonical path to AWS IMDSv1 credential theft, internal API enumeration, and lateral movement from your AI agent layer into your broader infrastructure. A public PoC is already available, and with 59 prior CVEs in this package, Flowise is an actively researched attack surface—despite a low absolute EPSS of 0.045%, it sits in the 86th percentile of all CVEs by exploitation likelihood. Upgrade to Flowise 3.1.0 immediately and layer network-level egress controls blocking RFC 1918 ranges and cloud metadata IPs as defense-in-depth.

Sources:NVDEPSSGitHub AdvisoryATLASCISA KEV

What is the risk?

CVSS 7.1 HIGH with AC:H reflects the DNS rebinding timing requirement, but the default-configuration path (no deny list enforced at all) creates a lower-complexity, near-trivial exploitation route that does not require DNS timing control. PoC availability significantly compresses exploitation timelines. CISA SSVC 'ATTEND' indicates active monitoring is warranted. Cloud-deployed Flowise instances face elevated risk due to reachable metadata services. The package's history of 59 CVEs signals sustained attacker interest and a pattern of security deficiencies.

How does the attack unfold?

Initial Access

Attacker obtains low-privileged access to a Flowise instance (or targets a public-facing deployment) and creates a workflow with an HTTP request node pointing to an attacker-controlled domain.

AML.T0049

SSRF Security Bypass

Attacker exploits DNS rebinding TOCTOU: allow-list check resolves to a permitted IP, but actual HTTP request after DNS TTL expiry resolves to a target internal IP; on default configs, no DNS manipulation is needed—direct internal IP requests pass without any deny list check.

AML.T0053

Internal Reconnaissance

Using SSRF access, attacker probes cloud metadata endpoints (169.254.169.254), internal APIs, and private network services unreachable from the public internet.

AML.T0075

Credential Harvesting & Impact

Attacker retrieves IAM credentials from cloud metadata service or extracts secrets from internal services, enabling cloud privilege escalation, lateral movement, and data exfiltration across the organization's infrastructure.

AML.T0083

Initial Access

Attacker obtains low-privileged access to a Flowise instance (or targets a public-facing deployment) and creates a workflow with an HTTP request node pointing to an attacker-controlled domain.

AML.T0049

SSRF Security Bypass

Attacker exploits DNS rebinding TOCTOU: allow-list check resolves to a permitted IP, but actual HTTP request after DNS TTL expiry resolves to a target internal IP; on default configs, no DNS manipulation is needed—direct internal IP requests pass without any deny list check.

AML.T0053

Internal Reconnaissance

Using SSRF access, attacker probes cloud metadata endpoints (169.254.169.254), internal APIs, and private network services unreachable from the public internet.

AML.T0075

Credential Harvesting & Impact

Attacker retrieves IAM credentials from cloud metadata service or extracts secrets from internal services, enabling cloud privilege escalation, lateral movement, and data exfiltration across the organization's infrastructure.

AML.T0083

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.1 / 10

EPSS

0.3%

chance of exploitation in 30 days

Higher than 18% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Trivial

Exploitation Confidence

medium

○CISA SSVC: Public PoC

○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?

AVNetwork

ACHigh

PRLow

UINone

SUnchanged

CHigh

IHigh

ALow

What should I do?

5 steps

PATCH
Upgrade Flowise to 3.1.0 or later—this is the only complete remediation.
NETWORK ISOLATION
Restrict Flowise outbound traffic via security groups or firewall rules; block RFC 1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) and cloud metadata IPs (169.254.169.254, fd00:ec2::254) at the network layer regardless of patch status.
CLOUD HARDENING
Enable IMDSv2 on all AWS EC2 instances to require session tokens, neutralizing metadata SSRF impact even if exploitation occurs.
DENY LIST AUDIT
Verify that Flowise deny lists are explicitly configured and not relying on defaults; treat any Flowise instance running pre-3.1.0 with default config as fully SSRF-exposed.
DETECTION
Monitor Flowise HTTP logs for requests to internal IP ranges or metadata service addresses; alert on DNS responses with very short TTLs (<5 seconds) originating from Flowise processes.

What does CISA's SSVC say?

DecisionAttend

Exploitationpoc

AutomatableNo

Technical Impacttotal

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

How is it classified?

Auth BypassData ExtractionAgentFrameworkAML.T0049- Exploit Public-Facing Application AML.T0053- AI Agent Tool Invocation AML.T0075- Cloud Service Discovery AML.T0083- Credentials from AI Agent Configuration AML.T0084- Discover AI Agent Configuration

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15-Accuracy, robustness and cybersecurity

ISO 42001

A.9.2-Information security controls for AI systems

NIST AI RMF

MANAGE 2.2-Mechanisms for updating and correcting identified deficiencies

OWASP LLM Top 10

LLM06:2025-Excessive Agency

Frequently Asked Questions

What is CVE-2026-41272?

Flowise's HTTP security wrappers—specifically designed to block SSRF—can be defeated through DNS rebinding (a Time-of-Check Time-of-Use race against the allow-list resolver) or, more trivially, by targeting the default configuration which enforces no deny list whatsoever. This is a direct threat to any enterprise running Flowise in cloud environments: SSRF is the canonical path to AWS IMDSv1 credential theft, internal API enumeration, and lateral movement from your AI agent layer into your broader infrastructure. A public PoC is already available, and with 59 prior CVEs in this package, Flowise is an actively researched attack surface—despite a low absolute EPSS of 0.045%, it sits in the 86th percentile of all CVEs by exploitation likelihood. Upgrade to Flowise 3.1.0 immediately and layer network-level egress controls blocking RFC 1918 ranges and cloud metadata IPs as defense-in-depth.

Is CVE-2026-41272 actively exploited?

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

How to fix CVE-2026-41272?

1. PATCH: Upgrade Flowise to 3.1.0 or later—this is the only complete remediation. 2. NETWORK ISOLATION: Restrict Flowise outbound traffic via security groups or firewall rules; block RFC 1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) and cloud metadata IPs (169.254.169.254, fd00:ec2::254) at the network layer regardless of patch status. 3. CLOUD HARDENING: Enable IMDSv2 on all AWS EC2 instances to require session tokens, neutralizing metadata SSRF impact even if exploitation occurs. 4. DENY LIST AUDIT: Verify that Flowise deny lists are explicitly configured and not relying on defaults; treat any Flowise instance running pre-3.1.0 with default config as fully SSRF-exposed. 5. DETECTION: Monitor Flowise HTTP logs for requests to internal IP ranges or metadata service addresses; alert on DNS responses with very short TTLs (<5 seconds) originating from Flowise processes.

What systems are affected by CVE-2026-41272?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, LLM workflow orchestration, cloud-hosted AI applications, internal API integrations.

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

CVE-2026-41272 has a CVSS v3.1 base score of 7.1 (HIGH). The EPSS exploitation probability is 0.26%.

What is the AI security impact?

Affected AI Architectures

agent frameworksLLM workflow orchestrationcloud-hosted AI applicationsinternal API integrations

MITRE ATLAS Techniques

AML.T0049Exploit Public-Facing Application

AML.T0053AI Agent Tool Invocation

AML.T0075Cloud Service Discovery

AML.T0083Credentials from AI Agent Configuration

AML.T0084Discover AI Agent Configuration

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.9.2

NIST AI RMF: MANAGE 2.2

OWASP LLM Top 10: LLM06:2025

What are the technical details?

Original Advisory

Flowise is a drag & drop user interface to build a customized large language model flow. Prior to 3.1.0, the core security wrappers (secureAxiosRequest and secureFetch) intended to prevent Server-Side Request Forgery (SSRF) contain multiple logic flaws. These flaws allow attackers to bypass the allow/deny lists via DNS Rebinding (Time-of-Check Time-of-Use) or by exploiting the default configuration which fails to enforce any deny list. This vulnerability is fixed in 3.1.0.

Exploitation Scenario

An attacker with a low-privileged Flowise account registers attacker.com with an A record pointing to an allowed external IP and a TTL of 1 second. They build a Flowise workflow with an HTTP request node targeting attacker.com. The secureAxiosRequest wrapper resolves the domain, confirms it maps to an allowed IP, and permits the request. Simultaneously, the attacker's authoritative DNS server flips the record to 169.254.169.254. The actual HTTP request—made milliseconds after the allow-list check—now hits the AWS metadata endpoint. The attacker retrieves IAM role credentials from /latest/meta-data/iam/security-credentials/, uses them to call AWS APIs, and pivots across the cloud environment. On default Flowise configurations with no deny list enforced, the timing attack is unnecessary—direct requests to internal IPs succeed immediately without DNS manipulation, reducing the attack to a simple HTTP call.

Weaknesses (CWE)

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.