CVE-2026-10546: Langflow: SSRF via DNS rebinding in URL component

MEDIUM
Published June 30, 2026
CISO Take

IBM Langflow's URL-loading component contains a Server-Side Request Forgery flaw rooted in a Time-of-Check/Time-of-Use race condition, allowing an attacker to bypass hostname validation via DNS rebinding and force the server to fetch attacker-chosen internal resources. The high confidentiality impact (C:H) means this can be used to reach cloud metadata endpoints, internal APIs, or other services on the Langflow host's network that were never meant to be internet-reachable, and no authentication is required to trigger the request. Exploitation requires high attack complexity — the attacker must win a DNS-rebinding race — which keeps the EPSS score low (0.00146) and explains why it isn't in CISA KEV and has no public exploit or Nuclei template yet; treat that as a temporary state rather than a reason to deprioritize, since SSRF-via-DNS-rebinding is a well-understood technique with mature public tooling. Any team running Langflow to build LLM pipelines that ingest URLs (web loaders, RAG document fetchers, tool integrations) should check IBM's advisory for a patched version, restrict outbound network access from the Langflow host with an egress allowlist, and disable or sandbox the URL data-source component until patched. Detection teams should watch for repeated/rapid DNS resolution changes for the same hostname immediately preceding outbound requests from the Langflow service.

Sources: NVD EPSS ATLAS

What is the risk?

Medium overall risk (CVSS 6.5): the vulnerability is network-reachable and needs no privileges or user interaction, but the attack complexity is high because it depends on winning a TOCTOU race via DNS rebinding, which limits reliability and mass-exploitability. Impact is meaningful — high confidentiality loss from SSRF typically enables access to cloud metadata services (credential theft), internal admin panels, or other services segmented behind the Langflow host. Absence from CISA KEV, no public PoC, and low EPSS (bottom of exploited-in-the-wild range despite a 96th percentile ranking within EPSS's own distribution) indicate this is not yet under active attack, but SSRF/DNS-rebinding chains are a known, well-documented attack class with existing public tooling, so the barrier to a working exploit is more about effort than novel research.

How does the attack unfold?

Reconnaissance & setup
Attacker identifies a Langflow deployment with an exposed URL data-source component and registers a domain they control for DNS rebinding.
AML.T0006
Initial access via public-facing exploitation
Attacker submits the attacker-controlled URL into a Langflow flow, triggering the URL component's fetch logic.
AML.T0049
TOCTOU exploitation via DNS rebinding
Attacker rebinds DNS from a benign IP (passes validation) to an internal/restricted IP before the actual fetch occurs, exploiting the race condition.
Impact: internal data disclosure
Langflow's backend issues the request to the internal target on the attacker's behalf, and the response (e.g., metadata credentials or internal service data) is exposed back to the attacker through the flow output.

What systems are affected?

Package Ecosystem Vulnerable Range Patched
Langflow pip No patch
153.3K Pushed 2d ago 24% patched ~70d to patch Full package profile →

Do you use Langflow? You're affected.

How severe is it?

CVSS 3.1
6.5 / 10
EPSS
0.1%
chance of exploitation in 30 days
Higher than 4% of all CVEs
Exploitation Status
No known exploitation
Sophistication
Moderate

What is the attack surface?

AV AC PR UI S C I A
AV Network
AC High
PR None
UI None
S Unchanged
C High
I Low
A None

What should I do?

1 step
  1. Upgrade to the patched Langflow release referenced in IBM's advisory as soon as it's available for your version line; until then, disable or restrict the URL/data_source component for non-trusted users. Apply network-level egress controls (firewall/proxy allowlists) so the Langflow host cannot reach internal-only IP ranges, link-local addresses (169.254.0.0/16, incl. cloud metadata endpoints), or other sensitive internal services. Where feasible, front outbound HTTP fetches with a validating forward proxy that re-resolves and re-checks the destination IP at request time (mitigating the TOCTOU gap) rather than trusting a single validate-then-connect check. For detection, monitor Langflow's outbound traffic for requests to internal/RFC1918 or link-local destinations, and flag hostnames whose DNS resolution changes shortly before a fetch (classic DNS-rebinding signature).

What does CISA's SSVC say?

Decision Track
Exploitation none
Automatable No
Technical Impact partial

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

How is it classified?

Which compliance frameworks are affected?

This CVE is relevant to:

ISO 42001
A.6.2.4 - AI system operation and monitoring
NIST AI RMF
MANAGE-2.3 - Third-party AI system risks are managed
OWASP LLM Top 10
LLM08 - Excessive Agency / Insecure Plugin Design

Frequently Asked Questions

What is CVE-2026-10546?

IBM Langflow's URL-loading component contains a Server-Side Request Forgery flaw rooted in a Time-of-Check/Time-of-Use race condition, allowing an attacker to bypass hostname validation via DNS rebinding and force the server to fetch attacker-chosen internal resources. The high confidentiality impact (C:H) means this can be used to reach cloud metadata endpoints, internal APIs, or other services on the Langflow host's network that were never meant to be internet-reachable, and no authentication is required to trigger the request. Exploitation requires high attack complexity — the attacker must win a DNS-rebinding race — which keeps the EPSS score low (0.00146) and explains why it isn't in CISA KEV and has no public exploit or Nuclei template yet; treat that as a temporary state rather than a reason to deprioritize, since SSRF-via-DNS-rebinding is a well-understood technique with mature public tooling. Any team running Langflow to build LLM pipelines that ingest URLs (web loaders, RAG document fetchers, tool integrations) should check IBM's advisory for a patched version, restrict outbound network access from the Langflow host with an egress allowlist, and disable or sandbox the URL data-source component until patched. Detection teams should watch for repeated/rapid DNS resolution changes for the same hostname immediately preceding outbound requests from the Langflow service.

Is CVE-2026-10546 actively exploited?

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

How to fix CVE-2026-10546?

Upgrade to the patched Langflow release referenced in IBM's advisory as soon as it's available for your version line; until then, disable or restrict the URL/data_source component for non-trusted users. Apply network-level egress controls (firewall/proxy allowlists) so the Langflow host cannot reach internal-only IP ranges, link-local addresses (169.254.0.0/16, incl. cloud metadata endpoints), or other sensitive internal services. Where feasible, front outbound HTTP fetches with a validating forward proxy that re-resolves and re-checks the destination IP at request time (mitigating the TOCTOU gap) rather than trusting a single validate-then-connect check. For detection, monitor Langflow's outbound traffic for requests to internal/RFC1918 or link-local destinations, and flag hostnames whose DNS resolution changes shortly before a fetch (classic DNS-rebinding signature).

What systems are affected by CVE-2026-10546?

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

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

CVE-2026-10546 has a CVSS v3.1 base score of 6.5 (MEDIUM). The EPSS exploitation probability is 0.15%.

What is the AI security impact?

Affected AI Architectures

agent frameworksRAG pipelinesLLM orchestration/flow builders

MITRE ATLAS Techniques

AML.T0010.005 AI Agent Tool
AML.T0049 Exploit Public-Facing Application

Compliance Controls Affected

ISO 42001: A.6.2.4
NIST AI RMF: MANAGE-2.3
OWASP LLM Top 10: LLM08

What are the technical details?

Original Advisory

IBM Langflow OSS 1.0.0 through 1.9.3 contains a Server-Side Request Forgery (SSRF) vulnerability in the URL component ( src/lfx/src/lfx/components/data_source/url.py ) due to a Time-of-Check/Time-of-Use (TOCTOU) race condition that can be exploited via DNS rebinding.

Exploitation Scenario

An attacker with access to a Langflow flow builder (or the ability to submit a URL into a flow that includes the URL data-source component) registers a domain whose DNS record they control. They first resolve the domain to a benign, allow-listed IP so Langflow's initial validation check passes, then rapidly rebind the DNS record to an internal IP (e.g., the cloud metadata service or an internal admin API) before Langflow actually issues the fetch — exploiting the gap between check and use. Langflow's backend then makes the HTTP request on the attacker's behalf to the internal target, returning the response (e.g., cloud credentials or internal service data) back into the flow's output, which the attacker can read via the UI or API, achieving unauthorized read access to internal-only resources.

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.

CVSS Vector

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N

Timeline

Published
June 30, 2026
Last Modified
July 2, 2026
First Seen
June 30, 2026

Related Vulnerabilities