CVE-2026-121559: 
GLPI vulnerability analysis and mitigation

CVE-2026-121559 is a privilege escalation vulnerability in GLPI (Gestionnaire Libre de Parc Informatique) that allows authenticated users with lower-privileged roles to obtain Super-Admin access by exploiting the user account cloning feature. It affects GLPI versions 10.0.0 through 10.0.27 and 11.0.0 through 11.0.9. The vulnerability was published on November 3, 2026, with patches released in versions 10.0.28 and 11.0.10. It carries a CVSS v3.1 base score of 7.2 (High) and a CVSS v4.0 base score of 8.6 (High) (Github Advisory, GLPI Advisory).

The root cause is classified as CWE-269 (Improper Privilege Management). The vulnerable function User::getCloneRelations() in src/User.php previously included Profile_User::class and Group_User::class in its return array, causing the cloning operation to blindly copy all profile and group assignments from the source account to the cloned account without any permission checks. An authenticated attacker with a Technician profile can invoke the user cloning feature against a Super-Admin account, specifying arbitrary credentials for the clone; the system then copies all Profile_User and Group_User records from the source to the new account, yielding a fully attacker-controlled Super-Admin account. The fix moves profile and group assignment copying to a new post_clone() method that checks $profile_user->can(-1, CREATE, $data) before copying each assignment, ensuring only permissions the cloning user could legitimately grant are transferred (GLPI Commit 10a827c, GLPI Commit d30faa5).

Successful exploitation grants the attacker a fully attacker-controlled Super-Admin account within GLPI, resulting in complete compromise of confidentiality, integrity, and availability of the GLPI system. With Super-Admin access, an attacker can read all IT asset data, helpdesk tickets, and user credentials stored in GLPI; modify or delete any records; create additional backdoor accounts; and potentially pivot to connected systems if GLPI is integrated with other infrastructure tools. The scope is limited to the GLPI application itself, but the administrative access obtained could facilitate broader lateral movement within an organization's IT management environment (Github Advisory, GLPI Advisory).

No public proof-of-concept exploit code has been identified, and there is no evidence of in-the-wild exploitation at the time of disclosure (Github Advisory). The EPSS score is approximately 0.488% (42nd percentile), indicating a relatively low but non-negligible probability of exploitation within 30 days. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires an authenticated account with at least Technician-level privileges, which limits the attack surface compared to unauthenticated vulnerabilities, but insider threats or compromised Technician accounts represent a realistic attack path.

1. Obtain Technician credentials: Acquire valid GLPI credentials for an account with at least the Technician profile, either through phishing, credential stuffing, or insider access.
2. Log in to GLPI: Authenticate to the target GLPI instance (versions 10.0.0–10.0.27 or 11.0.0–11.0.9) using the Technician account.
3. Identify a Super-Admin account: Browse the GLPI user management interface to locate an existing Super-Admin account (e.g., the default glpi administrator account).
4. Clone the Super-Admin account: Use the GLPI user cloning feature on the Super-Admin account, specifying attacker-chosen credentials (username and password) for the new cloned account.
5. Privilege escalation occurs: Due to the missing permission check in User::getCloneRelations(), the cloning operation copies all Profile_User and Group_User assignments from the Super-Admin source to the new account without validation.
6. Log in as Super-Admin: Authenticate to GLPI using the newly created account with the attacker-chosen credentials, now possessing full Super-Admin privileges.
7. Post-exploitation: With Super-Admin access, perform actions such as creating additional backdoor accounts, exfiltrating sensitive IT asset and helpdesk data, modifying configurations, or disabling legitimate administrator accounts (GLPI Advisory, GLPI Commit 10a827c).

• Logs: GLPI audit logs showing a user clone operation (clone action on a User object) performed by a Technician-level account targeting a Super-Admin account; log entries for new user account creation immediately followed by Super-Admin profile assignment.
• Database: Unexpected entries in the glpi_profiles_users table associating a newly created user account with a Super-Admin profile, where the creating session belonged to a non-admin user; review glpi_logs table for clone events (itemtype = 'User', linked_action indicating clone).
• Application: Presence of recently created user accounts (check glpi_users.date_creation) with Super-Admin profile assignments that were not provisioned through normal administrative workflows; multiple Super-Admin accounts where only one or a few are expected.
• Network: Authenticated HTTP POST requests to GLPI user management endpoints (e.g., /front/user.form.php) with parameters indicating a clone operation (_clone or similar), originating from Technician-level sessions.

Upgrade GLPI to version 10.0.28 (for the 10.0.x branch) or 11.0.10 (for the 11.0.x branch), which contain the fix that adds permission checks before copying profile and group assignments during user cloning (GLPI Advisory). As an interim workaround if immediate patching is not possible, restrict the user cloning capability to Super-Admin accounts only through GLPI's profile permission settings, and implement audit logging for all account cloning operations. Additionally, review existing user accounts — particularly those with Super-Admin profiles created recently — for unauthorized clones, and remove any suspicious accounts found.