CVE-2026-121937 in Loonflow
Summary
by MITRE • 11/04/2026
loonflow before r3.2.3 contains a missing authorization vulnerability in TicketFlowHistoryView that allows any authenticated user to read other users' ticket flow history by supplying a ticket UUID. Attackers can request the ticket_flow_history endpoint, which skips ticket_view_permission_check, to obtain approval comments and processor names, emails and phone numbers.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 11/04/2026
The vulnerability identified in LoonFlow versions prior to r3.2.3 represents a critical failure in access control mechanisms within the TicketFlowHistoryView component. This flaw is classified as an Insecure Direct Object Reference (IDOR), which corresponds to CWE-639, and falls under the category of Broken Access Control as defined by OWASP Top 10 security risks. The core issue stems from a logical error in the backend API endpoint responsible for retrieving ticket flow history. Specifically, the function handling requests to this endpoint fails to enforce proper authorization checks before processing user input. In a secure implementation, any request accessing sensitive data related to another entity must verify that the requesting authenticated user has explicit permission to view that specific resource. However, in this vulnerable version, the code path for fetching ticket flow history bypasses the standard ticket_view_permission_check routine entirely. This architectural oversight means that the system does not validate whether the current session owner is authorized to interact with the target ticket identified by its universally unique identifier (UUID).
As a direct consequence of this missing authorization check, any authenticated user can exploit the vulnerability by crafting HTTP requests to the ticket_flow_history endpoint and supplying arbitrary UUIDs belonging to other users' tickets. Since the system does not verify ownership or role-based permissions for these specific historical records, it returns detailed information associated with those tickets regardless of who is making the request. This allows an attacker to enumerate sensitive operational data across the organization without needing elevated privileges or prior knowledge of valid ticket IDs beyond simple enumeration techniques. The ability to access this data indiscriminately undermines the fundamental principle of least privilege and compromises the confidentiality guarantees expected in enterprise workflow management systems.
The operational impact of this vulnerability is significant due to the nature of the data exposed. By exploiting this flaw, an attacker can obtain approval comments which may contain confidential business strategies or internal critiques not intended for general staff visibility. Furthermore, the exposure includes processor names along with their associated emails and phone numbers. This constitutes a severe privacy violation and facilitates further malicious activities such as targeted phishing attacks, social engineering campaigns, or credential stuffing attempts against specific individuals within the organization. The leakage of personal contact information also poses compliance risks under data protection regulations like GDPR or CCPA, potentially resulting in legal liabilities for the affected organizations. Additionally, access to approval comments can reveal internal decision-making processes and hierarchical structures that could be leveraged by competitors or malicious insiders to gain strategic advantages.
To mitigate this vulnerability, immediate action is required to upgrade LoonFlow to version r3.2.3 or later where these authorization checks have been properly implemented in the TicketFlowHistoryView logic. Until an upgrade can be performed, administrators should consider implementing a reverse proxy rule that restricts access to the ticket_flow_history endpoint based on strict validation of user identity against resource ownership at the network level if possible. It is also advisable to conduct a thorough audit of other API endpoints within the application to ensure no similar patterns of missing authorization checks exist elsewhere in the codebase. Regular security assessments and penetration testing focused on broken access control scenarios are recommended to identify and remediate such flaws proactively before they can be exploited by adversaries seeking to harvest sensitive organizational data.