Loading vulnerability…
IDOR/BOLA in Langflow Monitor API
CVE-2026-33760 is a high-severity insecure direct object reference / broken object level authorization vulnerability in Langflow affecting versions prior to 1.9.0. The flaw is in the /api/v1/monitor router, where seven endpoints perform read, write, rename, and delete operations on user-owned resources without verifying that the authenticated requester owns the targeted object. Affected resources include messages, sessions, build artifacts, and LLM transaction logs. An authenticated attacker can supply another user's resource ID or flow_id to access or manipulate that user's data across tenant boundaries. The advisory notes that the same monitor.py file contains one correctly implemented ownership check, indicating the secure authorization pattern existed but was not consistently applied across the vulnerable endpoints.
What it means and what to do now: patch path, interim mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
Successful exploitation allows any authenticated user to compromise confidentiality, integrity, and availability of other users' data. An attacker can read sensitive messages, sessions, build artifacts, and LLM transaction logs, including potentially sensitive prompts, responses, and workflow-related data; modify or rename other users' resources; and permanently delete targeted data. In multi-user deployments this enables cross-tenant unauthorized access and destructive actions.
If you can’t patch tonight, do this now.
If immediate patching is not possible, restrict Langflow to single-user or otherwise fully trusted-user deployments, disable open or self-service registration, and limit exposure of the affected /api/v1/monitor endpoints using reverse proxy or API gateway controls. Apply network segmentation and strong authentication to reduce exposure of multi-user instances until the upgrade is completed.
Patch, then assume compromise.
Upgrade Langflow to version 1.9.0 or later, which fixes the vulnerability. Ensure all affected /api/v1/monitor endpoints enforce object-level authorization by validating that the requested resource is owned by the authenticated user, for example by tying access checks to the associated Flow.user_id before permitting read, update, rename, or delete operations. Review similar endpoints for consistent ownership enforcement.
No public exploits tracked yet. Mallory keeps watching.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
3 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.