CVE-2026-105029 in community-skeleton
Summary
by MITRE • 10/03/2026
UVdesk support-center-bundle before 1.1.3.3 contains an insecure direct object reference vulnerability in the rateTicket action of Controller/Ticket.php that allows authenticated customers to rate other customers' tickets. Attackers can supply arbitrary ticket IDs, which are loaded without an ownership check, to submit or change satisfaction ratings on tickets owned by other customers.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/03/2026
The UVdesk support-center-bundle prior to version 1.1.3.3 contains a critical insecure direct object reference vulnerability within the rateTicket action of its Ticket controller. This flaw stems from a fundamental failure in access control logic, specifically regarding how user identity is validated against resource ownership during rating operations. In secure application design, any operation that modifies or retrieves data associated with a specific entity must verify that the requesting user has explicit permission to interact with that particular instance. However, in this implementation, the system accepts arbitrary ticket identifiers provided by the authenticated client without performing an integrity check to ensure those tickets belong to the submitting user. This absence of object-level authorization allows any logged-in customer to manipulate satisfaction ratings for tickets they do not own, effectively bypassing intended business logic constraints and compromising the integrity of the support feedback mechanism.
From a technical perspective, this vulnerability is classified under CWE-639, which denotes an Insecure Direct Object Reference (IDOR). The attacker exploits this by crafting HTTP requests that target specific ticket IDs found through enumeration or other means. Since the backend processes these identifiers directly without cross-referencing them against the current session's user account data structure, it assumes validity based solely on the presence of a valid authentication token rather than proper authorization context. This allows malicious actors to submit false satisfaction ratings, potentially inflating scores for competitors' tickets or deflating scores for specific entities by manipulating public-facing metrics. The impact extends beyond mere metric manipulation; it undermines trust in the support platform's feedback system and can be leveraged as a vector for social engineering if these ratings are displayed publicly or used internally to gauge agent performance unfairly.
In terms of operational security, this vulnerability aligns with MITRE ATT&CK technique T1078, specifically relating to Valid Accounts where an attacker uses legitimate credentials but abuses their permissions through flawed logic rather than privilege escalation. The ability to alter ticket ratings can lead to significant reputational damage for support agents or teams if the system relies on these metrics for performance evaluations. Furthermore, it represents a breach of data integrity principles, as the stored state of customer satisfaction becomes unreliable and susceptible to manipulation by any authenticated user with minimal effort. This type of flaw is particularly dangerous because it does not require complex exploitation chains; it can be executed manually via browser developer tools or automated scripts using standard HTTP methods like POST or PUT against the vulnerable endpoint.
To mitigate this vulnerability, developers must implement strict object-level authorization checks within the rateTicket action before processing any rating updates. The application logic should query the database to verify that the ticket ID provided in the request is explicitly associated with the user ID present in the current authentication session. If a mismatch occurs between the requesting user and the ticket owner, the system must reject the operation immediately with an appropriate error code rather than proceeding silently or returning misleading success messages. Additionally, implementing rate limiting on rating submissions can help prevent automated abuse campaigns that attempt to flood specific tickets with fake ratings. Upgrading to version 1.1.3.3 or later is essential as it addresses these access control deficiencies by enforcing proper ownership validation during the rating workflow. Regular security audits focusing on IDOR patterns in all CRUD operations are recommended to ensure similar flaws do not exist elsewhere in the application architecture.