CVE-2026-10129: Langflow SSRF protection bypass

CISO Take

IBM Langflow's API Request component fails to re-validate redirect destinations, so an authenticated low-privilege "flow author" can enable follow_redirects, point at a public URL they control, and have it 302 into localhost, internal services, or the cloud metadata endpoint — defeating the SSRF filter entirely. This matters because Langflow flows are routinely built by non-admin business users or contractors, and a successful bypass can leak cloud IAM credentials, internal API tokens, and admin-panel data straight into the flow's visible output, which is a serious blast radius for a CVSS 8.5 (C:H) finding. There's no CISA KEV listing, no public exploit, and no Nuclei template, and EPSS sits at just 0.00185, so mass opportunistic exploitation is unlikely today — but the risk is real wherever the flow-author role is granted broadly (contractors, business users, low-trust internal teams). Patch to the fixed Langflow release referenced in IBM's advisory, and until then hard-restrict or disable the follow_redirects parameter and block egress to RFC1918 ranges and 169.254.169.254 at the network layer. Audit who currently holds flow-author privileges, since this bug is only exploitable by someone who already has that role.

Sources: NVD EPSS ATLAS ibm.com

What is the risk?

High severity (CVSS 8.5) driven by a confidentiality impact of High (C:H) — an SSRF bypass here can expose cloud IAM credentials, internal API tokens, and admin data. However, exploitability is gated by PR:L (requires an authenticated flow-author account, not anonymous access), and there is no evidence of active exploitation: EPSS is very low (0.00185), the CVE is absent from CISA KEV, and no public exploit code or Nuclei scanner template exists. The realistic threat model is an insider, a compromised low-privilege account, or a malicious contractor with flow-building access — not internet-wide scanning. Risk scales with how permissively organizations assign the flow-author role and how close the Langflow deployment sits to sensitive internal services or cloud metadata endpoints.

How does the attack unfold?

Authenticated low-privilege access

Attacker obtains or already holds a Langflow account with the low-privilege flow-author role.

AML.T0012

SSRF bypass configuration

Attacker builds a flow with the API Request component, targets a public URL they control, and enables follow_redirects.

AML.T0049

Internal resource access

The attacker-controlled URL redirects the server-side request to an internal service, localhost endpoint, or cloud metadata service that Langflow's SSRF filter never re-validates.

AML.T0075

Credential/data exposure

The internal response (credentials, tokens, admin data) is returned in the flow's output, which the attacker reads directly from the Langflow UI or API.

AML.T0055

Authenticated low-privilege access

Attacker obtains or already holds a Langflow account with the low-privilege flow-author role.

AML.T0012

SSRF bypass configuration

Attacker builds a flow with the API Request component, targets a public URL they control, and enables follow_redirects.

AML.T0049

Internal resource access

The attacker-controlled URL redirects the server-side request to an internal service, localhost endpoint, or cloud metadata service that Langflow's SSRF filter never re-validates.

AML.T0075

Credential/data exposure

The internal response (credentials, tokens, admin data) is returned in the flow's output, which the attacker reads directly from the Langflow UI or API.

AML.T0055

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

8.5 / 10

EPSS

0.2%

chance of exploitation in 30 days

Higher than 8% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What is the attack surface?

AV Network

AC Low

PR Low

UI None

S Changed

C High

I Low

A None

What should I do?

1 step

1) Upgrade Langflow past 1.9.3 to the version specified in IBM's advisory (https://www.ibm.com/support/pages/node/7277561) that fixes redirect re-validation. 2) Until patched, disable the follow_redirects option on the API Request component, or restrict it via policy/RBAC so only trusted admin roles can enable it. 3) Enforce SSRF protection at the network layer, independent of the application: deny egress from the Langflow host to RFC1918/loopback ranges and to 169.254.169.254, and require IMDSv2 with a low hop-limit on cloud metadata services. 4) Review and tighten who holds the flow-author role — treat it as a privileged role, not a default one. 5) Monitor Langflow server egress/access logs for outbound requests to internal IP ranges or metadata endpoints originating from flow executions, and alert on redirect chains terminating in non-public destinations.

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?

Auth Bypass Data Leakage Framework API AML.T0049 - Exploit Public-Facing Application AML.T0055 - Unsecured Credentials 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

8.2 - AI system impact assessment / operational control

NIST AI RMF

MANAGE 4.1 - Post-deployment monitoring of AI system risks

OWASP LLM Top 10

LLM06 - Excessive Agency

Frequently Asked Questions

What is CVE-2026-10129?

IBM Langflow's API Request component fails to re-validate redirect destinations, so an authenticated low-privilege "flow author" can enable follow_redirects, point at a public URL they control, and have it 302 into localhost, internal services, or the cloud metadata endpoint — defeating the SSRF filter entirely. This matters because Langflow flows are routinely built by non-admin business users or contractors, and a successful bypass can leak cloud IAM credentials, internal API tokens, and admin-panel data straight into the flow's visible output, which is a serious blast radius for a CVSS 8.5 (C:H) finding. There's no CISA KEV listing, no public exploit, and no Nuclei template, and EPSS sits at just 0.00185, so mass opportunistic exploitation is unlikely today — but the risk is real wherever the flow-author role is granted broadly (contractors, business users, low-trust internal teams). Patch to the fixed Langflow release referenced in IBM's advisory, and until then hard-restrict or disable the follow_redirects parameter and block egress to RFC1918 ranges and 169.254.169.254 at the network layer. Audit who currently holds flow-author privileges, since this bug is only exploitable by someone who already has that role.

Is CVE-2026-10129 actively exploited?

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

How to fix CVE-2026-10129?

1) Upgrade Langflow past 1.9.3 to the version specified in IBM's advisory (https://www.ibm.com/support/pages/node/7277561) that fixes redirect re-validation. 2) Until patched, disable the follow_redirects option on the API Request component, or restrict it via policy/RBAC so only trusted admin roles can enable it. 3) Enforce SSRF protection at the network layer, independent of the application: deny egress from the Langflow host to RFC1918/loopback ranges and to 169.254.169.254, and require IMDSv2 with a low hop-limit on cloud metadata services. 4) Review and tighten who holds the flow-author role — treat it as a privileged role, not a default one. 5) Monitor Langflow server egress/access logs for outbound requests to internal IP ranges or metadata endpoints originating from flow executions, and alert on redirect chains terminating in non-public destinations.

What systems are affected by CVE-2026-10129?

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

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

CVE-2026-10129 has a CVSS v3.1 base score of 8.5 (HIGH). The EPSS exploitation probability is 0.18%.

What is the AI security impact?

Affected AI Architectures

agent frameworksRAG pipelines

MITRE ATLAS Techniques

AML.T0049 Exploit Public-Facing Application

AML.T0055 Unsecured Credentials

AML.T0075 Cloud Service Discovery

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: 8.2

NIST AI RMF: MANAGE 4.1

OWASP LLM Top 10: LLM06

What are the technical details?

Original Advisory

IBM Langflow OSS 1.0.0 through 1.9.3 contains a Server-Side Request Forgery (SSRF) protection bypass vulnerability in the API Request component. An authenticated attacker with low-level privileges (flow author role) can bypass SSRF protections by enabling the follow_redirects parameter and supplying a public URL that redirects to internal/localhost addresses. The vulnerability exists because the application validates only the initial URL but does not re-validate redirect destinations. This allows attackers to access internal HTTP services, localhost endpoints, cloud metadata services, and private network resources that should be unreachable when SSRF protection is enabled. Successful exploitation can lead to disclosure of sensitive information including credentials, tokens, internal API responses, and administrative panel data.

Exploitation Scenario

An attacker holding a low-privilege "flow author" account (e.g., a contractor, business analyst, or compromised low-trust credential) builds a Langflow flow using the API Request component. They set the target URL to an external domain they control and enable follow_redirects. That external domain is configured to issue a 302 redirect to an internal target — for example http://169.254.169.254/latest/meta-data/iam/security-credentials/ for cloud credentials, or http://localhost:8080/admin for a co-located admin panel. Because Langflow's SSRF filter only inspects the original public URL and never re-validates the redirect destination, the server-side request proceeds, and the response — credentials, tokens, or internal API data — is rendered directly in the flow's output, which the attacker reads from the Langflow UI or API without needing any separate exfiltration channel.

Weaknesses (CWE)

CWE-918 Server-Side Request Forgery (SSRF) Primary CWE-918 Server-Side Request Forgery (SSRF)

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.