CVE-2026-7657: Langflow: SSRF bypass exposes internal network/cloud data

MEDIUM

Published August 5, 2026

CISO Take

Langflow, a widely deployed low-code framework for building LLM/agent workflows, ships incomplete SSRF protections that let an authenticated low-privilege user coerce the server into making arbitrary outbound HTTP requests. The CVSS 6.5 score reflects a confidentiality-only impact (C:H/I:N/A:N), but in practice SSRF against a self-hosted AI orchestration server is a pivot point into cloud metadata endpoints, internal APIs, and adjacent AI infrastructure like vector databases or model-serving hosts — exactly the kind of blast radius that matters for teams running Langflow in production. There's no public exploit or Nuclei template yet, it's not in CISA KEV, EPSS sits low, and CISA's SSVC decision is TRACK, so this is not an emergency-patch-tonight situation. Still, with 112 other CVEs already logged against this package and a risk score of 77/100, Langflow has a track record worth taking seriously. Patch to the fixed release referenced in IBM's advisory, and in the meantime restrict Langflow's outbound network access (deny access to 169.254.169.254 and internal RFC1918 ranges) at the egress firewall or container network policy.

Sources:NVDEPSSCISA KEVATLASibm.com

What is the risk?

Medium severity (CVSS 6.5) with low attack complexity and no user interaction required, but privileges are required (PR:L) — an attacker needs at least a low-privileged account on the Langflow instance to trigger it. Confidentiality impact is high; integrity and availability are unaffected, consistent with a classic SSRF read-only data exposure. Exploitation likelihood signals are all low right now (EPSS 0.00201, not in KEV, no public PoC/exploit, no Nuclei template, SSVC TRACK), so this is not an actively exploited or high-urgency threat today. The real risk driver is exposure: any Langflow deployment reachable by semi-trusted users (internal teams, multi-tenant SaaS builders, shared dev environments) and running in cloud infrastructure with metadata services enabled is a meaningful target, since the flaw is described as 'incomplete and ineffective SSRF protection' — implying the existing allowlist/denylist can be bypassed rather than being wholly absent.

How does the attack unfold?

Initial Access

An authenticated low-privilege Langflow user creates or edits a flow component (e.g. HTTP request node) that accepts a destination URL.

AML.T0049

SSRF Exploitation

The user crafts a URL targeting internal or cloud metadata endpoints that bypasses Langflow's incomplete SSRF filter, and the server issues the forged request.

AML.T0075

Data Exfiltration

The response from the internal/metadata service (credentials, internal data) is returned through the flow output and viewed by the attacker.

AML.T0025

Impact / Pivot

Leaked cloud credentials or internal API access are used to pivot further into cloud infrastructure or adjacent AI services like vector databases or model-serving endpoints.

AML.T0106

Initial Access

An authenticated low-privilege Langflow user creates or edits a flow component (e.g. HTTP request node) that accepts a destination URL.

AML.T0049

SSRF Exploitation

The user crafts a URL targeting internal or cloud metadata endpoints that bypasses Langflow's incomplete SSRF filter, and the server issues the forged request.

AML.T0075

Data Exfiltration

The response from the internal/metadata service (credentials, internal data) is returned through the flow output and viewed by the attacker.

AML.T0025

Impact / Pivot

Leaked cloud credentials or internal API access are used to pivot further into cloud infrastructure or adjacent AI services like vector databases or model-serving endpoints.

AML.T0106

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

6.5 / 10

EPSS

0.4%

chance of exploitation in 30 days

Higher than 32% 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

CHigh

INone

ANone

What should I do?

1 step

Patch: upgrade to the fixed Langflow release referenced in IBM's advisory (https://www.ibm.com/support/pages/node/7282650) as soon as it's validated in your environment — the affected range is 1.0.0 through 1.10.3. Workaround until patched: apply network-level egress controls around the Langflow host/container — block outbound access to 169.254.169.254 (and equivalent GCP/Azure metadata IPs) and to internal-only RFC1918 ranges the app doesn't legitimately need, via firewall, security group, or container network policy (defense-in-depth beyond the app's own filter, since the app-layer filter is what's broken here). Restrict which users can create/edit flow components that accept arbitrary URLs, and review existing flows for HTTP-request-style nodes pointing at unexpected internal targets. Detection: monitor outbound connections from the Langflow host for requests to metadata IPs or internal-only hosts, and review Langflow audit/access logs for low-privilege accounts modifying URL-accepting components shortly before anomalous outbound traffic.

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?

Data ExtractionAuth BypassFrameworkAgentAML.T0025- Exfiltration via Cyber Means AML.T0049- Exploit Public-Facing Application AML.T0075- Cloud Service Discovery AML.T0106- Exploitation for Credential Access

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15-Accuracy, robustness and cybersecurity

ISO 42001

A.6.2-Security of AI systems

NIST AI RMF

MEASURE 2.7-AI system security and resilience are evaluated and documented

OWASP LLM Top 10

LLM07-Insecure Plugin/Component Design

Frequently Asked Questions

What is CVE-2026-7657?

Is CVE-2026-7657 actively exploited?

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

How to fix CVE-2026-7657?

Patch: upgrade to the fixed Langflow release referenced in IBM's advisory (https://www.ibm.com/support/pages/node/7282650) as soon as it's validated in your environment — the affected range is 1.0.0 through 1.10.3. Workaround until patched: apply network-level egress controls around the Langflow host/container — block outbound access to 169.254.169.254 (and equivalent GCP/Azure metadata IPs) and to internal-only RFC1918 ranges the app doesn't legitimately need, via firewall, security group, or container network policy (defense-in-depth beyond the app's own filter, since the app-layer filter is what's broken here). Restrict which users can create/edit flow components that accept arbitrary URLs, and review existing flows for HTTP-request-style nodes pointing at unexpected internal targets. Detection: monitor outbound connections from the Langflow host for requests to metadata IPs or internal-only hosts, and review Langflow audit/access logs for low-privilege accounts modifying URL-accepting components shortly before anomalous outbound traffic.

What systems are affected by CVE-2026-7657?

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

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

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

What is the AI security impact?

Affected AI Architectures

agent frameworksRAG pipelinesmodel servingvector databases

MITRE ATLAS Techniques

AML.T0025Exfiltration via Cyber Means

AML.T0049Exploit Public-Facing Application

AML.T0075Cloud Service Discovery

AML.T0106Exploitation for Credential Access

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.6.2

NIST AI RMF: MEASURE 2.7

OWASP LLM Top 10: LLM07

What are the technical details?

Original Advisory

IBM Langflow OSS 1.0.0 through 1.10.3 Langflow could allow server-side request forgery (SSRF) due to incomplete and ineffective SSRF protection enforcement.

Exploitation Scenario

An attacker who has (or obtains) a low-privileged account on a shared or multi-tenant Langflow instance builds or edits a flow using a component that accepts a destination URL — for example an HTTP request node or a custom tool node. They craft the URL to target the cloud instance metadata service or an internal-only admin API, using an encoding or path trick that slips past Langflow's SSRF filter (the advisory calls it 'incomplete and ineffective'). The Langflow server executes the request on the attacker's behalf and returns the response — credentials, internal service data, or configuration — back through the flow's output, which the attacker views in the UI or via the API. With cloud credentials in hand, the attacker can pivot to broader cloud resources, or with internal API access they can reach other AI infrastructure (vector DBs, model-serving endpoints) that isn't meant to be reachable from Langflow's user-facing surface.

Weaknesses (CWE)

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