CVE-2026-9081: Langflow SSRF — HIGH

CISO Take

Langflow's Ollama provider key-check function takes a user-supplied OLLAMA_BASE_URL and fetches it server-side with no scheme, host, or private-IP filtering, letting an authenticated low-privilege user turn the Langflow server into an SSRF proxy into your internal network. The confidentiality impact is rated high (CVSS 7.1, C:H/I:L/A:N), which matters because this class of bug is routinely used to reach cloud instance-metadata endpoints (AWS IMDS, GCP metadata) and steal IAM credentials, or to fingerprint internal services that were never meant to be reachable from the app tier. It is not in CISA KEV, has no public exploit or Nuclei template, EPSS sits at 0.17%, and CISA's own SSVC call is TRACK — the lowest urgency tier — so this is not an active-exploitation emergency today. That said, Langflow already carries 112 other CVEs and a 77/100 package risk score, so treat this as one more data point in a broader pattern of insufficient input validation rather than an isolated bug; patch when IBM's advisory publishes a fixed version, and in the meantime block outbound access from the Langflow host to 169.254.169.254 and RFC1918 ranges at the network layer.

Sources: NVD EPSS CISA KEV ibm.com ATLAS

What is the risk?

Moderate near-term risk, elevated by exposure context. Exploitation requires only low privileges (PR:L), no user interaction, and low attack complexity — an authenticated Langflow user (even a non-admin builder role) can trigger the flaw by pointing OLLAMA_BASE_URL at an internal target. Offsetting factors: no active exploitation observed, no public PoC or scanner signature, EPSS probability is low (0.17th percentile of raw score), and CISA SSVC rates it TRACK. The real risk driver is deployment context — Langflow instances running inside cloud VPCs with reachable instance-metadata services, or instances that allow self-service signup/low-trust accounts, face materially higher exposure than tightly access-controlled internal deployments.

How does the attack unfold?

Initial Access

Attacker obtains or is granted a low-privileged, authenticated Langflow account (self-service signup or compromised credential).

AML.T0012

Exploitation

Attacker sets OLLAMA_BASE_URL to an internal or cloud-metadata address in a flow's Ollama provider config, triggering an unvalidated server-side request.

AML.T0049

Discovery

The server-side response reveals internal service data or cloud IAM credentials pulled from the metadata endpoint.

AML.T0075

Impact

Attacker uses harvested credentials or internal reconnaissance to pivot toward broader cloud/internal-network compromise.

AML.T0055

Initial Access

Attacker obtains or is granted a low-privileged, authenticated Langflow account (self-service signup or compromised credential).

AML.T0012

Exploitation

Attacker sets OLLAMA_BASE_URL to an internal or cloud-metadata address in a flow's Ollama provider config, triggering an unvalidated server-side request.

AML.T0049

Discovery

The server-side response reveals internal service data or cloud IAM credentials pulled from the metadata endpoint.

AML.T0075

Impact

Attacker uses harvested credentials or internal reconnaissance to pivot toward broader cloud/internal-network compromise.

AML.T0055

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Langflow	pip	—	No patch
155.0K Pushed yesterday 17% patched ~70d to patch Full package profile →

Do you use Langflow? You're affected.

How severe is it?

CVSS 3.1

7.1 / 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 Unchanged

C High

I Low

A None

What should I do?

1 step

1) Check IBM's advisory (support.ibm.com node/7282650) for a fixed Langflow version and upgrade — the current data does not confirm a patched release above 1.10.3, so track this actively. 2) Until patched, enforce egress filtering from the Langflow host: block outbound requests to 169.254.169.254 (cloud metadata), 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, and loopback addresses at the firewall/security-group layer — do not rely on application-layer fixes alone. 3) Restrict who can create/edit flows with Ollama provider nodes to trusted/admin roles if your Langflow RBAC configuration allows it. 4) If Ollama integration isn't in active use, disable that provider entirely. 5) Detection: monitor Langflow host egress logs and cloud VPC flow logs for outbound requests to metadata IPs or unexpected internal RFC1918 destinations originating from the Langflow process.

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?

Data Leakage Framework Agent 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

NIST AI RMF

MEASURE 2.7 - AI system security and resilience evaluated

OWASP LLM Top 10

LLM02 - Sensitive Information Disclosure

Frequently Asked Questions

What is CVE-2026-9081?

Langflow's Ollama provider key-check function takes a user-supplied OLLAMA_BASE_URL and fetches it server-side with no scheme, host, or private-IP filtering, letting an authenticated low-privilege user turn the Langflow server into an SSRF proxy into your internal network. The confidentiality impact is rated high (CVSS 7.1, C:H/I:L/A:N), which matters because this class of bug is routinely used to reach cloud instance-metadata endpoints (AWS IMDS, GCP metadata) and steal IAM credentials, or to fingerprint internal services that were never meant to be reachable from the app tier. It is not in CISA KEV, has no public exploit or Nuclei template, EPSS sits at 0.17%, and CISA's own SSVC call is TRACK — the lowest urgency tier — so this is not an active-exploitation emergency today. That said, Langflow already carries 112 other CVEs and a 77/100 package risk score, so treat this as one more data point in a broader pattern of insufficient input validation rather than an isolated bug; patch when IBM's advisory publishes a fixed version, and in the meantime block outbound access from the Langflow host to 169.254.169.254 and RFC1918 ranges at the network layer.

Is CVE-2026-9081 actively exploited?

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

How to fix CVE-2026-9081?

1) Check IBM's advisory (support.ibm.com node/7282650) for a fixed Langflow version and upgrade — the current data does not confirm a patched release above 1.10.3, so track this actively. 2) Until patched, enforce egress filtering from the Langflow host: block outbound requests to 169.254.169.254 (cloud metadata), 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, and loopback addresses at the firewall/security-group layer — do not rely on application-layer fixes alone. 3) Restrict who can create/edit flows with Ollama provider nodes to trusted/admin roles if your Langflow RBAC configuration allows it. 4) If Ollama integration isn't in active use, disable that provider entirely. 5) Detection: monitor Langflow host egress logs and cloud VPC flow logs for outbound requests to metadata IPs or unexpected internal RFC1918 destinations originating from the Langflow process.

What systems are affected by CVE-2026-9081?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, LLM orchestration pipelines, model serving.

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

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

What is the AI security impact?

Affected AI Architectures

agent frameworksLLM orchestration pipelinesmodel serving

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

NIST AI RMF: MEASURE 2.7

OWASP LLM Top 10: LLM02

What are the technical details?

Original Advisory

IBM Langflow OSS 1.0.0 through 1.10.3, and 1.0.0 through 1.10.3 contains a Server-Side Request Forgery (SSRF) vulnerability in the validate_model_provider_key() function for the Ollama provider. The function accepts a user-supplied OLLAMA_BASE_URL parameter and passes it directly to requests.get() without validation, scheme/host allowlisting, or filtering of private IP ranges (loopback, RFC1918, link-local addresses).

Exploitation Scenario

An attacker obtains or is granted a low-privileged Langflow account (self-service signup, or a compromised builder credential). They create or edit a flow, add an Ollama model node, and set OLLAMA_BASE_URL to http://169.254.169.254/latest/meta-data/iam/security-credentials/ instead of a legitimate Ollama server address. When the flow validates the provider key, Langflow's backend issues a server-side GET to that URL with no allowlist check; if the response — or even just error/behavior differences — is surfaced back to the user, the attacker harvests cloud IAM credentials or fingerprints internal services (databases, admin panels, other microservices on the VPC) that should never be internet- or user-reachable, using those credentials for lateral movement into the broader cloud environment.

Weaknesses (CWE)

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