CVE-2026-10564: Langflow SSRF Vulnerability

CVE-2026-10564 Overview

CVE-2026-10564 is a Server-Side Request Forgery (SSRF) vulnerability affecting IBM Langflow OSS versions 1.0.0 through 1.9.6. The flaw resides in the legacy RSSReaderComponent (rss.py) and the SearXNG component (searxng.py), which issue unvalidated HTTP requests to user-controlled URLs. These components bypass SSRF protections introduced in version 1.9.3. An authenticated attacker can pivot to internal resources, including cloud metadata endpoints on AWS, Azure, and GCP. Successful exploitation enables Identity and Access Management (IAM) credential exfiltration and internal network enumeration. The vulnerability is also reachable via prompt injection in agentic workflows because both components expose tool_mode=True [CWE-918].

Critical Impact
Authenticated attackers can reach cloud Instance Metadata Service (IMDS) endpoints, harvest IAM credentials, and enumerate internal networks through Langflow components.

Affected Products

IBM Langflow OSS 1.0.0 through 1.9.6
Deployments using the legacy RSSReaderComponent in rss.py
Deployments using the SearXNG component in searxng.py

Discovery Timeline

2026-06-30 - CVE-2026-10564 published to NVD
2026-07-02 - Last updated in NVD database

Technical Details for CVE-2026-10564

Vulnerability Analysis

Langflow is a low-code framework for building agentic and Retrieval-Augmented Generation (RAG) workflows. Version 1.9.3 introduced centralized SSRF protections intended to validate outbound HTTP request targets. Two components were not migrated to the hardened request path. The RSSReaderComponent in rss.py and the SearXNG component in searxng.py continue to make direct HTTP requests to attacker-supplied URLs. The requests originate from the Langflow server, allowing the attacker to reach hosts and ports that are otherwise unreachable from the public internet.

Root Cause

The root cause is missing URL validation prior to outbound HTTP requests in the two legacy components. Neither component enforces the deny lists, private-address filtering, or scheme restrictions applied elsewhere in Langflow 1.9.3+. Because both components declare tool_mode=True, they are exposed as callable tools to Large Language Model (LLM) agents. Prompt injection payloads processed by an agent can therefore invoke the vulnerable request path without direct operator interaction.

Attack Vector

An authenticated user submits a workflow that includes the RSSReaderComponent or SearXNG component with a target URL pointing to internal infrastructure. Typical targets include the AWS IMDSv1 endpoint at 169.254.169.254, the Azure IMDS host, or the GCP metadata server. The Langflow server issues the HTTP request and returns the response body to the workflow. The attacker parses the response to extract short-lived IAM credentials, project identifiers, or internal service banners. In agentic deployments, an untrusted document or upstream tool response containing a crafted instruction can cause the agent to invoke the same components, producing indirect prompt injection SSRF.

No public proof-of-concept has been published. The vulnerability requires network access to a Langflow instance and valid authentication.

Detection Methods for CVE-2026-10564

Indicators of Compromise

Outbound HTTP requests from the Langflow server to 169.254.169.254, metadata.google.internal, or Azure IMDS host 169.254.169.254 with the Metadata: true header.
Langflow application logs referencing RSSReaderComponent or SearXNG with URLs pointing to RFC1918 addresses, localhost, or link-local ranges.
Unexpected use of tool_mode=True invocations of rss.py or searxng.py during agent runs.
Cloud audit logs showing API calls authenticated with the Langflow host role from unusual source IPs shortly after workflow execution.

Detection Strategies

Inspect egress traffic from Langflow hosts and alert on connections to metadata service IPs and internal CIDR ranges.
Deploy egress filtering that logs and blocks HTTP requests to link-local and private ranges, then treat any blocked attempt from Langflow as a high-severity signal.
Correlate Langflow component invocation logs with outbound network flows to identify SSRF attempts originating from workflow execution.

Monitoring Recommendations

Enable Langflow audit logging and forward records to a centralized Security Information and Event Management (SIEM) platform.
Monitor the Langflow service account and instance role for anomalous cloud API activity, particularly sts:GetCallerIdentity and credential-issuing calls.
Alert on any invocation of RSSReaderComponent or SearXNG in production tenants where those components are not required.

How to Mitigate CVE-2026-10564

Immediate Actions Required

Upgrade Langflow to a fixed release above 1.9.6 as published by IBM in the IBM Support Page.
Disable or remove the RSSReaderComponent and SearXNG components from available component sets until patching is complete.
Enforce IMDSv2 with hop-limit 1 on AWS EC2 instances hosting Langflow to block credential theft via SSRF.
Rotate any IAM credentials, API tokens, or service account keys accessible to the Langflow host role.

Patch Information

IBM has published remediation guidance and fixed versions on the IBM Support Page. Apply the fixed release across all Langflow deployments, including development and staging environments used for agent testing.

Workarounds

Restrict Langflow egress traffic with a network policy that denies access to 169.254.0.0/16, 127.0.0.0/8, and internal RFC1918 ranges except for required backend services.
Run Langflow under a minimally scoped cloud identity with no permissions beyond what workflows require.
Require authentication and role-based access control for workflow creation, and prohibit untrusted users from adding components that perform outbound HTTP.
Sanitize or sandbox inputs to agentic workflows to reduce prompt injection risk against tool_mode=True components.

bash

# Example: block metadata service access from the Langflow host (Linux iptables)
iptables -A OUTPUT -d 169.254.169.254 -j REJECT
iptables -A OUTPUT -d 169.254.170.2 -j REJECT
iptables -A OUTPUT -d 127.0.0.0/8 ! -o lo -j REJECT