CVE-2026-114392 in Trudesk
Summary
by MITRE • 10/22/2026
Trudesk through 1.2.11 contains an authorization bypass vulnerability that allows authenticated users to read tickets outside their groups via GET /api/v1/tickets/:uid. Attackers can enumerate sequential ticket uids to read every ticket's subject, issue, comments, owner and assignee, because the apiTickets.single handler skips group membership checks.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/22/2026
The vulnerability identified in Trudesk versions through 1.2.11 represents a critical authorization bypass within the application’s API layer, specifically targeting the endpoint GET /api/v1/tickets/:uid. This flaw stems from an insufficient access control mechanism where the server-side handler responsible for retrieving individual ticket details fails to validate whether the authenticated user requesting the data belongs to the same group as the ticket owner or assignee. In a properly secured multi-tenant or team-based environment, such as Trudesk which is designed for IT service management and help desk operations, access to specific resources must be strictly gated by role-based or attribute-based permissions that verify group membership before returning sensitive data. The absence of this check allows any authenticated user with valid credentials to bypass the intended logical boundaries between different teams or departments within the organization.
From a technical perspective, the root cause lies in the implementation of the apiTickets.single handler. When an API request is made for a specific ticket identified by its unique identifier (uid), the application retrieves the corresponding record from the database but neglects to perform a secondary verification step against the user’s assigned groups or roles. This oversight creates a direct path for information disclosure, as the system trusts the validity of the provided uid without ensuring that the requester has legitimate authorization to view the contents associated with that identifier. Consequently, an attacker can exploit this logic error by iterating through sequential ticket uids, effectively enumerating all tickets in the system regardless of their privacy settings or group restrictions.
The operational impact of this vulnerability is significant for organizations relying on Trudesk for managing sensitive support requests and internal communications. Since attackers can enumerate sequential identifiers to access every ticket’s subject, issue description, comments, owner, and assignee, they gain comprehensive visibility into the organization’s operational workflows and potentially confidential business information. This level of unauthorized access facilitates further reconnaissance efforts, allowing adversaries to map out organizational structures by identifying key personnel through assigned owners or recipients. Furthermore, the exposure of detailed issue descriptions and internal discussions may reveal security configurations, system architectures, or other sensitive data that could be leveraged for more targeted attacks such as social engineering or privilege escalation attempts against specific individuals within the organization.
This vulnerability aligns with CWE-284 Improper Access Control, specifically reflecting a failure to enforce proper authorization checks on API endpoints. In terms of offensive security frameworks, this behavior corresponds to ATT&CK technique T1078 Valid Accounts, where an attacker uses legitimate credentials to access resources they are not authorized for, and potentially T1592 Gather Victim Host Information if the enumerated data is used to profile targets. The ability to sequentially enumerate uids also touches upon aspects of information gathering that could be categorized under reconnaissance activities aimed at mapping out application state through predictable identifier patterns.
To mitigate this vulnerability, organizations running Trudesk versions prior to 1.2.12 must upgrade immediately to the patched version where the authorization logic has been corrected to enforce group membership checks for all ticket retrieval operations. Until an update can be applied, administrators should consider implementing network-level controls such as Web Application Firewalls that monitor API traffic for patterns indicative of enumeration attacks, although this is a compensatory measure rather than a fix. It is also advisable to review audit logs for any signs of unauthorized access attempts using sequential uid values and rotate credentials if there is evidence of exploitation. Ensuring that all users operate with the principle of least privilege can further reduce the blast radius should similar vulnerabilities exist elsewhere in the application, limiting the potential damage an authenticated attacker could inflict even after bypassing specific endpoint checks.