Yzeirnials

**Name of the Vulnerable Software and Affected Versions** Langflow versions prior to 1.9.1 **Description** An Insecure Direct Object Reference (IDOR) issue exists in the `/api/v1/responses` endpoint. This occurs because the `get flow by id or endpoint name()` function fails to verify if the authenticated user owns the flow when it is accessed via a UUID. An authenticated attacker can execute any flow belonging to another user by specifying the victim's flow ID in the `model` parameter. This can lead to the execution of unauthorized workflows, consumption of other users' resources, and access to sensitive data processed by those flows. **Recommendations** Update Langflow to version 1.9.1 or later. As a temporary mitigation, restrict access to the `/api/v1/responses` endpoint to trusted users only.

**Name of the Vulnerable Software and Affected Versions** Langflow versions prior to 1.9.0 **Description** The `/api/v1/monitor` router exposes seven endpoints that allow read, write, and delete operations on user-owned resources, including messages, sessions, build artifacts, and LLM transaction logs. The system fails to verify if the authenticated requester owns the targeted resource, leading to an Insecure Direct Object Reference (IDOR), also known as Broken Object Level Authorization (BOLA). An authenticated user can read, modify, rename, or permanently delete another user's data by providing the target's resource ID or `flow id`. Technical details include the following vulnerable endpoints: - 'GET /api/v1/monitor/builds' and 'DELETE /api/v1/monitor/builds' using the `flow id` variable. - 'DELETE /api/v1/monitor/messages' using the `message ids` variable. - 'PUT /api/v1/monitor/messages/{message id}' using the `message id` variable. - 'PATCH /api/v1/monitor/messages/session/{old session id}' using the `old session id` variable. - 'DELETE /api/v1/monitor/messages/session/{session id}' using the `session id` variable. - 'GET /api/v1/monitor/transactions' using the `flow id` variable. **Recommendations** Update to version 1.9.0. As a temporary workaround, restrict access to the `/api/v1/monitor` endpoints to minimize the risk of unauthorized data access or deletion.