Description

UVdesk core-framework before 1.1.7 contains an improper privilege management vulnerability in the editAgent endpoint that allows agents with agent-management privilege to escalate their own role to administrator. Attackers can submit their own account identifier with a role parameter set to ROLE_ADMIN to gain full administrative control over agents, tickets, and mail configuration.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.2",
  "pubDate": "2026-09-21T14:17:14.897Z",
  "pubdate": "2026-09-21T14:17:14.897Z",
  "executiveSummary": "UVdesk core-framework versions prior to 1.1.7 are susceptible to an improper privilege management vulnerability located within the agent management module.\nThe vulnerability allows an authenticated attacker possessing existing 'agent-management' privileges to perform a vertical privilege escalation, effectively promoting their account to the administrative role (ROLE_ADMIN).\nBy manipulating the parameters sent to the editAgent endpoint, a malicious agent can bypass authorization checks to modify their own account's role.\nThe exploitation of this flaw grants the attacker full administrative control over the UVdesk platform, including unrestricted access to customer support tickets, global mail configurations, and user management settings.\nThis represents a critical security failure, as it enables lateral movement and persistent compromise of the helpdesk infrastructure. Exploitation requires an existing, lower-privileged agent account, but does not necessitate further user interaction or complex bypasses once the administrative role is assigned.\nOrganizations relying on affected versions of the UVdesk core-framework are at significant risk of unauthorized data access and total administrative compromise if an internal account is compromised.",
  "technicalDetails": "The vulnerability exists due to insufficient server-side validation of user-submitted input within the 'editAgent' functionality of the UVdesk core-framework.\nSpecifically, the application fails to enforce strict access control policies or input sanitization when processing agent modification requests. While the endpoint is designed to allow authorized managers to modify agent details, it lacks a mechanism to prevent an agent from modifying their own security context during the request lifecycle.\nThe attack flow initiates when an authenticated agent with 'agent-management' privileges submits a crafted POST or PUT request to the 'editAgent' endpoint. Within the request payload, the attacker includes their own user identifier or account reference, alongside a modified 'role' parameter set to 'ROLE_ADMIN'.\nBecause the server-side logic processes the input to update the database without confirming that the requester has the authority to promote themselves or that the target identifier does not correspond to the authenticated session's user, the application accepts the modified role parameter as valid instructions to alter the authorization metadata of the target account.\nUpon successful processing of the request, the application updates the agent's role within the backend database to 'ROLE_ADMIN'. This change is instantaneous and persistent, effectively elevating the attacker's authorization level to the highest tier of the application's privilege hierarchy.\nThe impact of this exploit is comprehensive. An elevated account gains the ability to execute administrative functions, such as deleting or reading sensitive support tickets, modifying SMTP/mail server settings, creating backdoors via new administrative users, and exfiltrating data stored within the helpdesk environment.\nThe vulnerable component is the user management logic responsible for processing updates in the editAgent workflow. Authentication is required to reach the endpoint, but the privilege check is flawed, as it allows a 'manager' role to assume an 'admin' role through the same interface designed for updating regular agent profiles.\nNo external network exposure is required beyond access to the authenticated agent interface, making this a classic vertical privilege escalation attack originating from an internal, albeit restricted, user account."
}