CVE-2025-71421: UVdesk Privilege Escalation Vulnerability

CVE-2025-71421 Overview

CVE-2025-71421 is an improper privilege management vulnerability [CWE-269] in UVdesk core-framework before version 1.1.7. The flaw resides in the editAgent endpoint within Controller/Account.php. Any authenticated agent holding the agent-management privilege can submit an edit request targeting their own account with the role parameter set to ROLE_ADMIN. The application accepts the request without verifying that the acting user is authorized to elevate their own role. Successful exploitation grants full administrative control over agents, tickets, and mail configuration.

Critical Impact
An authenticated agent with agent-management privilege can escalate to administrator, gaining full control over the helpdesk instance including all tickets, agent accounts, and mail server configuration.

Affected Products

UVdesk core-framework versions prior to 1.1.7
UVdesk community-skeleton deployments bundling vulnerable core-framework releases
Self-hosted UVdesk helpdesk instances built on affected framework versions

Discovery Timeline

2026-09-21 - CVE-2025-71421 published to NVD
2026-09-22 - Last updated in NVD database

Technical Details for CVE-2025-71421

Vulnerability Analysis

The vulnerability is a vertical privilege escalation in the agent editing workflow. UVdesk exposes an editAgent action that allows users with agent-management privilege to modify other agent records, including their support role. The controller reads the role field from user-supplied POST data and assigns the resolved SupportRole entity to the target userInstance without checking whether the acting user is permitted to change that specific role. Because the endpoint accepts an arbitrary agentId, an attacker can supply their own account identifier alongside role=ROLE_ADMIN. The framework then persists the administrative role against the attacker's own user record. The attacker gains administrator-level permissions on the next request, enabling changes to mail configuration, agent provisioning, and ticket data.

Root Cause

The root cause is missing authorization logic around role assignment. The pre-patch code path in Controller/Account.php at lines 278-282 unconditionally resolves and assigns the SupportRole when $data['role'] is set. There is no comparison between the acting user's identity and the agentId being modified, and no check preventing an agent from promoting themselves. The related AccountXHR.php code also called getSupportRole() and compared the returned object directly to a string, further weakening role enforcement.

Attack Vector

Exploitation requires an authenticated account with the agent-management privilege and network access to the UVdesk web interface. The attacker submits a crafted edit request against the editAgent endpoint containing their own agent identifier and role=ROLE_ADMIN. No user interaction from an administrator is required. Once the response confirms the update, the attacker holds administrator privileges and can pivot to modify mail transport settings, exfiltrate ticket contents, or create additional privileged accounts.

php

                     $oldSupportGroup  = ($supportGroupList = $userInstance != null ? $userInstance->getSupportGroups() : null) ? $supportGroupList->toArray() : [];
                     $oldSupportedPrivilege = ($supportPrivilegeList = $userInstance != null ? $userInstance->getSupportPrivileges() : null) ? $supportPrivilegeList->toArray() : [];
 
+                    if (isset($data['role'])) {
+                        if ($this->getUser()->getId() == $agentId && $this->getUser()->getRoles()[0] == "ROLE_AGENT" || $this->getUser()->getRoles()[0] =="ROLE_ADMIN") {
+                            $json['alertClass'] = 'warning';
+                            $json['alertMessage'] = $this->translator->trans("Warning ! You are not allowed to change your role.");
+                            return new Response(json_encode($json), 403, ['Content-Type' => 'application/json']);
+                        }
+                    }
+
                     if (isset($data['role'])) {
                         $role = $em->getRepository(SupportRole::class)->findOneBy(array('code' => $data['role']));
                         $userInstance->setSupportRole($role);

Source: GitHub Commit b8bcdc5. The patch inserts an authorization check that blocks agents from modifying their own role and returns HTTP 403 when the condition is met.

Detection Methods for CVE-2025-71421

Indicators of Compromise

HTTP POST requests to the editAgent endpoint where the request body contains role=ROLE_ADMIN and the target agentId matches the authenticated session's user ID.
Unexpected transitions of user records from ROLE_AGENT to ROLE_ADMIN in the UVdesk database user_instance table.
Newly created privileged agents, changes to SMTP or IMAP mail configuration, or bulk ticket exports shortly after an agent role change.

Detection Strategies

Audit UVdesk application logs for editAgent invocations and correlate the acting user ID with the modified agentId field to flag self-edits containing role changes.
Deploy a web application firewall rule that inspects POST bodies to /account/agent/* routes and blocks or alerts when role parameters are present.
Baseline the number of administrator accounts and alert on any growth outside of change-controlled provisioning windows.

Monitoring Recommendations

Enable database-level auditing on the user_instance and support_role tables to capture role reassignments with timestamps and originating session data.
Forward web server access logs and UVdesk application logs to a centralized analytics platform for correlation across authentication, authorization, and configuration change events.
Monitor outbound mail configuration changes and API tokens issued from administrator accounts for signs of post-exploitation activity.

How to Mitigate CVE-2025-71421

Immediate Actions Required

Upgrade UVdesk core-framework to version 1.1.7 or later. Community-skeleton operators should move to release v1.1.8 as referenced in the GitHub Release v1.1.8 notes.
Review all existing agent accounts and revoke any unexpected ROLE_ADMIN assignments. Reset credentials for accounts that were elevated without authorization.
Audit mail server configuration, API tokens, and recently created agents for unauthorized modifications made after any suspicious role change.

Patch Information

The fix is delivered in commit b8bcdc5 and shipped in core-framework release v1.1.7. Refer to the GitHub Release v1.1.7 notes and the VulnCheck Advisory for UVdesk for advisory context. The patch adds an authorization check in Controller/Account.php that rejects role changes when the acting user is editing their own agent record, and corrects the role comparison in Controller/AccountXHR.php to call getCode() on the returned SupportRole object.

Workarounds

Restrict the agent-management privilege to a small, trusted set of accounts until the upgrade is complete.
Place the UVdesk admin interface behind a VPN or IP allowlist to reduce exposure of the vulnerable editAgent endpoint.
Deploy a reverse-proxy or WAF rule that strips or rejects the role parameter on requests to the agent edit endpoint when the acting user is not a super administrator.

bash

# Example nginx rule to block self-service role changes on the editAgent endpoint
location ~ ^/en/account/agent/[0-9]+/edit$ {
    if ($request_method = POST) {
        if ($request_body ~* "role=ROLE_ADMIN") {
            return 403;
        }
    }
    proxy_pass http://uvdesk_backend;
}