CVE-2026-33760: Langflow IDOR exposes cross-user LLM

Q: Is CVE-2026-33760 actively exploited?

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

Q: How to fix CVE-2026-33760?

1. Patch: Upgrade all Langflow instances to version 1.9.0, which enforces ownership checks across the monitor API. 2. Workaround: If immediate patching is not possible, restrict to single-tenant deployments or apply network-level ACLs blocking access to /api/v1/monitor/* endpoints. 3. Detection: Review API access logs for monitor endpoint requests where the authenticated user's ID does not correspond to the target flow owner — cross-user flow_id access patterns are the primary indicator. 4. Incident response: Audit all /monitor/messages, /monitor/transactions, and /monitor/builds access logs since deployment to identify unauthorized cross-user data access. 5. Long-term: Enforce mandatory authorization pattern review (ownership JOIN against current_user.id) for all AI framework API additions.

Q: What systems are affected by CVE-2026-33760?

This vulnerability affects the following AI/ML architecture patterns: multi-user LLM application platforms, LLM agent frameworks, RAG pipelines, AI workflow automation, AI audit logging systems.

Q: What is the CVSS score for CVE-2026-33760?

CVE-2026-33760 has a CVSS v3.1 base score of 8.8 (HIGH). The EPSS exploitation probability is 0.36%.

CISO Take

Langflow versions prior to 1.9.0 contain a critical Broken Object Level Authorization (BOLA) flaw in its monitoring API where 7 endpoints perform read, write, and delete operations on user data without verifying resource ownership, allowing any authenticated user to silently read, tamper with, or permanently destroy another user's LLM conversation history, session logs, and build artifacts. In regulated deployments — healthcare, legal, HR, finance — the unprotected GET /monitor/transactions endpoint alone exposes HIPAA or GDPR-covered conversation content from any user's account by supplying only a known or enumerated flow_id. Exploitation is trivial, requiring only a valid account and no elevated privileges, and EPSS places this in the top 88th percentile for exploitation likelihood with 48 total CVEs already logged in this framework. All multi-user Langflow deployments should upgrade to 1.9.0 immediately; until patching is feasible, restrict to single-tenant use or block the /api/v1/monitor router at the network level.

Sources: NVD EPSS GitHub Advisory ATLAS

What is the risk?

High risk for any multi-user Langflow deployment. CVSS 8.8 reflects network-accessible exploitation requiring only low privileges with no user interaction, delivering full confidentiality, integrity, and availability impact. The attack surface is self-compounding: UUIDs can be harvested from the same vulnerable transaction endpoints, creating a self-reinforcing enumeration chain. The 48-CVE history and 77/100 package risk score indicate a pattern of insufficient authorization review in this codebase. Cloud-hosted, SaaS, and enterprise self-hosted multi-tenant instances are at highest risk.

How does the attack unfold?

Initial Access

Attacker registers or obtains a valid low-privileged Langflow account on a multi-user or SaaS instance — no special permissions required.

AML.T0012

Resource Enumeration

Attacker harvests victim flow_ids by enumerating UUIDs or reading message IDs returned in their own transaction logs, which reveal cross-user resource identifiers.

AML.T0049

Data Exfiltration

Attacker calls GET /monitor/transactions?flow_id=<victim_id> to extract full LLM conversation logs including sensitive prompts, model responses, and session metadata.

AML.T0085

Integrity Destruction

Attacker overwrites victim messages via PUT /monitor/messages/{id} to corrupt audit trails and bulk-deletes sessions via DELETE to permanently eliminate evidence of unauthorized access.

AML.T0092

Initial Access

Attacker registers or obtains a valid low-privileged Langflow account on a multi-user or SaaS instance — no special permissions required.

AML.T0012

Resource Enumeration

Attacker harvests victim flow_ids by enumerating UUIDs or reading message IDs returned in their own transaction logs, which reveal cross-user resource identifiers.

AML.T0049

Data Exfiltration

Attacker calls GET /monitor/transactions?flow_id=<victim_id> to extract full LLM conversation logs including sensitive prompts, model responses, and session metadata.

AML.T0085

Integrity Destruction

Attacker overwrites victim messages via PUT /monitor/messages/{id} to corrupt audit trails and bulk-deletes sessions via DELETE to permanently eliminate evidence of unauthorized access.

AML.T0092

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Langflow	pip	< 1.9.0	`1.9.0`
152.7K Pushed 6d ago 26% patched ~70d to patch Full package profile →

Do you use Langflow? You're affected.

How severe is it?

CVSS 3.1

8.8 / 10

EPSS

0.4%

chance of exploitation in 30 days

Higher than 28% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Trivial

Exploitation Confidence

medium

○ CISA SSVC: Public PoC

Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AV Network

AC Low

PR Low

UI None

S Unchanged

C High

I High

A High

What should I do?

5 steps

Patch: Upgrade all Langflow instances to version 1.9.0, which enforces ownership checks across the monitor API.
Workaround: If immediate patching is not possible, restrict to single-tenant deployments or apply network-level ACLs blocking access to /api/v1/monitor/* endpoints.
Detection: Review API access logs for monitor endpoint requests where the authenticated user's ID does not correspond to the target flow owner — cross-user flow_id access patterns are the primary indicator.
Incident response: Audit all /monitor/messages, /monitor/transactions, and /monitor/builds access logs since deployment to identify unauthorized cross-user data access.
Long-term: Enforce mandatory authorization pattern review (ownership JOIN against current_user.id) for all AI framework API additions.

What does CISA's SSVC say?

Decision Attend

Exploitation poc

Automatable No

Technical Impact total

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

How is it classified?

Auth Bypass Data Extraction Privacy Violation Framework Agent AML.T0012 - Valid Accounts AML.T0049 - Exploit Public-Facing Application AML.T0085 - Data from AI Services AML.T0092 - Manipulate User LLM Chat History

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 9 - Risk management system

ISO 42001

6.1.2 - AI risk assessment

NIST AI RMF

GOVERN-1.7 - Processes for identifying AI risks

OWASP LLM Top 10

LLM02:2025 - Sensitive Information Disclosure

Frequently Asked Questions

What is CVE-2026-33760?

Langflow versions prior to 1.9.0 contain a critical Broken Object Level Authorization (BOLA) flaw in its monitoring API where 7 endpoints perform read, write, and delete operations on user data without verifying resource ownership, allowing any authenticated user to silently read, tamper with, or permanently destroy another user's LLM conversation history, session logs, and build artifacts. In regulated deployments — healthcare, legal, HR, finance — the unprotected GET /monitor/transactions endpoint alone exposes HIPAA or GDPR-covered conversation content from any user's account by supplying only a known or enumerated flow_id. Exploitation is trivial, requiring only a valid account and no elevated privileges, and EPSS places this in the top 88th percentile for exploitation likelihood with 48 total CVEs already logged in this framework. All multi-user Langflow deployments should upgrade to 1.9.0 immediately; until patching is feasible, restrict to single-tenant use or block the /api/v1/monitor router at the network level.

Is CVE-2026-33760 actively exploited?

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

How to fix CVE-2026-33760?

1. Patch: Upgrade all Langflow instances to version 1.9.0, which enforces ownership checks across the monitor API. 2. Workaround: If immediate patching is not possible, restrict to single-tenant deployments or apply network-level ACLs blocking access to /api/v1/monitor/* endpoints. 3. Detection: Review API access logs for monitor endpoint requests where the authenticated user's ID does not correspond to the target flow owner — cross-user flow_id access patterns are the primary indicator. 4. Incident response: Audit all /monitor/messages, /monitor/transactions, and /monitor/builds access logs since deployment to identify unauthorized cross-user data access. 5. Long-term: Enforce mandatory authorization pattern review (ownership JOIN against current_user.id) for all AI framework API additions.

What systems are affected by CVE-2026-33760?

This vulnerability affects the following AI/ML architecture patterns: multi-user LLM application platforms, LLM agent frameworks, RAG pipelines, AI workflow automation, AI audit logging systems.

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

CVE-2026-33760 has a CVSS v3.1 base score of 8.8 (HIGH). The EPSS exploitation probability is 0.36%.

What is the AI security impact?

Affected AI Architectures

multi-user LLM application platformsLLM agent frameworksRAG pipelinesAI workflow automationAI audit logging systems

MITRE ATLAS Techniques

AML.T0012 Valid Accounts

AML.T0049 Exploit Public-Facing Application

AML.T0085 Data from AI Services

AML.T0092 Manipulate User LLM Chat History

Compliance Controls Affected

EU AI Act: Article 9

ISO 42001: 6.1.2

NIST AI RMF: GOVERN-1.7

OWASP LLM Top 10: LLM02:2025

What are the technical details?

Original Advisory

Langflow is a tool for building and deploying AI-powered agents and workflows. Prior to 1.9.0, Langflow's /api/v1/monitor router exposes 7 endpoints that perform read, write, and delete operations on user-owned resources — messages, sessions, build artifacts, and LLM transaction logs — without verifying that the authenticated requester owns the targeted resource. Any authenticated user can read, modify, rename, or permanently delete another user's data by supplying the target's resource ID or flow_id. This is a classic IDOR/BOLA vulnerability. Notably, the same source file (monitor.py) contains one correctly-implemented endpoint that uses an ownership check, demonstrating the correct pattern was known but inconsistently applied. This vulnerability is fixed in 1.9.0.

Exploitation Scenario

An attacker registers a free account on a shared or SaaS Langflow instance. They call GET /monitor/transactions using their own flow_id to confirm the endpoint is live, then enumerate UUIDs to discover victim flow_ids — or obtain them through social engineering or leaked identifiers. With a target flow_id in hand, the attacker extracts the full LLM conversation history including potentially sensitive system prompts and model responses. They harvest message IDs from the transaction dump and use PUT /monitor/messages/{id} to overwrite victim messages with attacker-controlled content, silently corrupting chat history and any downstream RAG indexes that consume stored messages. Finally, they bulk-delete victim sessions via DELETE /monitor/messages/session/{id} to eliminate evidence, leaving no recoverable audit trail.

Weaknesses (CWE)

CWE-639 Authorization Bypass Through User-Controlled Key Primary CWE-639 Authorization Bypass Through User-Controlled Key Primary CWE-639 Authorization Bypass Through User-Controlled Key

CWE-639 — Authorization Bypass Through User-Controlled Key: The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data.

[Architecture and Design] For each and every data access, ensure that the user has sufficient privilege to access the record that is being requested.
[Architecture and Design, Implementation] Make sure that the key that is used in the lookup of a specific user's record is not controllable externally by the user or that any tampering can be detected.

Source: MITRE CWE corpus.