CVE-2026-18545: Langflow SSRF lets authenticated

CISO Take

IBM Langflow versions 1.0.0 through 1.11.1 contain a server-side request forgery flaw (CWE-918) that lets an authenticated, low-privileged user coerce the Langflow server into issuing requests on their behalf. Because Langflow instances are frequently deployed with network access to internal services, cloud metadata endpoints, and other backend systems as part of agentic pipelines, this SSRF becomes a stepping stone for internal network enumeration and can facilitate follow-on attacks against services that trust the Langflow host's network position. There is no CISA KEV listing, no known public exploit or Nuclei template, and EPSS data is unavailable, so this is not an actively exploited or high-velocity threat today — but the CVSS 4.3 score understates the risk in cloud-hosted deployments where SSRF commonly pivots into IMDS credential theft. Any low-privileged account (including a compromised or malicious insider account) is sufficient to trigger it, with no user interaction required. Upgrade to a patched Langflow release beyond 1.11.1 as soon as IBM/Langflow publishes one, and in the meantime restrict Langflow's outbound network egress (deny access to cloud metadata IPs like 169.254.169.254 and internal-only ranges) and review authenticated-user permissions to limit who can create or edit flows with HTTP/URL-fetching components.

Sources:NVDATLASIBM support advisory

What is the risk?

Medium severity as scored (CVSS 4.3), driven by the requirement for low-privilege authentication and a confidentiality-only impact with no integrity or availability loss. However, real-world risk is context-dependent: Langflow is often deployed on cloud infrastructure with access to internal APIs, databases, or cloud metadata services, so the 'network enumeration or facilitating other attacks' impact described by IBM can escalate significantly if SSRF reaches sensitive internal endpoints. No active exploitation, KEV listing, or public PoC currently exists, and no EPSS/exploit-maturity data is available, so near-term opportunistic exploitation risk appears low. The bigger concern is targeted abuse by a malicious or compromised authenticated user (insider threat or stolen low-privilege credentials) rather than mass internet scanning.

How does the attack unfold?

Initial Access

Attacker obtains low-privileged authenticated access to a Langflow instance.

AML.T0012

Exploitation

Attacker configures a flow's HTTP/URL-fetch component with an internal or attacker-chosen destination, triggering SSRF.

AML.T0049

Discovery

The Langflow server issues requests on the attacker's behalf, enabling enumeration of internal hosts, services, and cloud metadata endpoints.

AML.T0075

Impact

Enumerated internal services or leaked metadata credentials facilitate further lateral movement or compromise beyond the Langflow host.

Initial Access

Attacker obtains low-privileged authenticated access to a Langflow instance.

AML.T0012

Exploitation

Attacker configures a flow's HTTP/URL-fetch component with an internal or attacker-chosen destination, triggering SSRF.

AML.T0049

Discovery

The Langflow server issues requests on the attacker's behalf, enabling enumeration of internal hosts, services, and cloud metadata endpoints.

AML.T0075

Impact

Enumerated internal services or leaked metadata credentials facilitate further lateral movement or compromise beyond the Langflow host.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Langflow	pip	—	No patch
156.2KPushed 4d ago18% patched~75d to patchFull package profile →

Do you use Langflow? You're affected.

How severe is it?

CVSS 3.1

4.3 / 10

EPSS

0.3%

chance of exploitation in 30 days

Higher than 23% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What is the attack surface?

AVNetwork

ACLow

PRLow

UINone

SUnchanged

CLow

INone

ANone

What should I do?

1 step

1) Upgrade Langflow past 1.11.1 once a fixed release is available from IBM/Langflow upstream — track the vendor advisory at the IBM support page referenced in this CVE. 2) In the interim, apply network-level egress controls on the host/container running Langflow: block outbound access to cloud metadata endpoints (169.254.169.254 for AWS/GCP/Azure), loopback, and internal RFC1918 ranges unless explicitly required by a flow. 3) Restrict which authenticated users can create/edit flows containing HTTP-request or URL-fetch components; treat flow-authoring permissions as a privileged capability, not a default user right. 4) Deploy Langflow behind a network segment with a deny-by-default egress policy and an allowlist of required external APIs. 5) For detection, monitor Langflow's outbound request logs for calls to internal IPs, metadata IPs, or unexpected ports/hosts, and alert on anomalous SSRF-pattern traffic (e.g., URL parameters resolving to internal hosts).

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?

Auth BypassData ExtractionFrameworkAgentAML.T0049- Exploit Public-Facing Application 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.2.6-AI system security

NIST AI RMF

MEASURE 2.7-AI system security and resilience

OWASP LLM Top 10

LLM08-Excessive Agency

Frequently Asked Questions

What is CVE-2026-18545?

IBM Langflow versions 1.0.0 through 1.11.1 contain a server-side request forgery flaw (CWE-918) that lets an authenticated, low-privileged user coerce the Langflow server into issuing requests on their behalf. Because Langflow instances are frequently deployed with network access to internal services, cloud metadata endpoints, and other backend systems as part of agentic pipelines, this SSRF becomes a stepping stone for internal network enumeration and can facilitate follow-on attacks against services that trust the Langflow host's network position. There is no CISA KEV listing, no known public exploit or Nuclei template, and EPSS data is unavailable, so this is not an actively exploited or high-velocity threat today — but the CVSS 4.3 score understates the risk in cloud-hosted deployments where SSRF commonly pivots into IMDS credential theft. Any low-privileged account (including a compromised or malicious insider account) is sufficient to trigger it, with no user interaction required. Upgrade to a patched Langflow release beyond 1.11.1 as soon as IBM/Langflow publishes one, and in the meantime restrict Langflow's outbound network egress (deny access to cloud metadata IPs like 169.254.169.254 and internal-only ranges) and review authenticated-user permissions to limit who can create or edit flows with HTTP/URL-fetching components.

Is CVE-2026-18545 actively exploited?

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

How to fix CVE-2026-18545?

1) Upgrade Langflow past 1.11.1 once a fixed release is available from IBM/Langflow upstream — track the vendor advisory at the IBM support page referenced in this CVE. 2) In the interim, apply network-level egress controls on the host/container running Langflow: block outbound access to cloud metadata endpoints (169.254.169.254 for AWS/GCP/Azure), loopback, and internal RFC1918 ranges unless explicitly required by a flow. 3) Restrict which authenticated users can create/edit flows containing HTTP-request or URL-fetch components; treat flow-authoring permissions as a privileged capability, not a default user right. 4) Deploy Langflow behind a network segment with a deny-by-default egress policy and an allowlist of required external APIs. 5) For detection, monitor Langflow's outbound request logs for calls to internal IPs, metadata IPs, or unexpected ports/hosts, and alert on anomalous SSRF-pattern traffic (e.g., URL parameters resolving to internal hosts).

What systems are affected by CVE-2026-18545?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, RAG pipelines, LLM orchestration/workflow builders.

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

CVE-2026-18545 has a CVSS v3.1 base score of 4.3 (MEDIUM). The EPSS exploitation probability is 0.30%.

What is the AI security impact?

Affected AI Architectures

agent frameworksRAG pipelinesLLM orchestration/workflow builders

MITRE ATLAS Techniques

AML.T0049Exploit Public-Facing Application

AML.T0075Cloud Service Discovery

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.6.2.6

NIST AI RMF: MEASURE 2.7

OWASP LLM Top 10: LLM08

What are the technical details?

Original Advisory

IBM Langflow OSS 1.0.0 through 1.11.1 is vulnerable to server-side request forgery (SSRF). This may allow an authenticated attacker to send unauthorized requests from the system, potentially leading to network enumeration or facilitating other attacks.

Exploitation Scenario

An attacker who has obtained low-privileged, authenticated access to a Langflow instance (e.g., via a shared internal deployment, a compromised low-level account, or an intentionally malicious insider) crafts or edits a flow component that accepts a user-controlled URL for an HTTP/webhook/tool-call node. Instead of pointing it at a legitimate external API, the attacker points it at an internal address — such as the cloud provider's instance metadata service, an internal admin panel, or another service on the private network — causing the Langflow server itself to issue the request. The response is then rendered back through the flow's output, letting the attacker enumerate internal hosts and services, fingerprint what's reachable from the Langflow host, and potentially retrieve sensitive data (like cloud IAM credentials from a metadata endpoint) to pivot deeper into the environment.

Weaknesses (CWE)

CWE-918Server-Side Request ForgeryPrimary 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.