CVE-2026-53627 in GLPI
Summary
by MITRE • 09/25/2026
GLPI is a free asset and IT management software package. From 11.0.0 until 11.0.8, a low-privileged authenticated user can use the new API (v2) to perform update operations that the same user is normally forbidden to perform through the user interface. The API update flow does not consistently enforce the applicable authorization checks. This issue is fixed in version 11.0.8.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/25/2026
GLPI, a widely deployed open-source IT asset and service management platform, suffered from an access control vulnerability affecting versions ranging from 11.0.0 through 11.0.8. The core of the issue lies in the implementation of its REST API version two interface, which serves as a programmatic entry point for external applications to interact with the system's data and configuration settings. While the graphical user interface correctly enforces role-based access controls that restrict certain administrative actions to users with elevated privileges, the corresponding logic within the API endpoint failed to replicate these security checks consistently. This discrepancy created an authorization bypass scenario where a low-privileged authenticated user could execute update operations on sensitive system resources or configurations without possessing the necessary permissions required for such tasks via the standard web interface.
The technical flaw stems from inconsistent enforcement of authorization policies between different entry points within the application architecture. In secure software design, access control checks must be centralized and uniformly applied to all methods that modify stateful data, regardless of whether the request originates from a browser-based form submission or an API call. The vulnerability indicates that the developers likely implemented permission validation for UI-driven requests but omitted equivalent verification steps in the API handler logic. Consequently, attackers who have obtained valid credentials with limited privileges can leverage this gap to perform administrative updates, such as modifying system configurations, altering user roles, or changing critical asset properties. This type of flaw is a classic example of broken access control, where the application trusts client-side restrictions or fails to validate server-side permissions for every distinct API method.
From an operational perspective, this vulnerability poses significant risks to the integrity and security posture of organizations relying on GLPI for IT service management. An attacker exploiting this issue could escalate their privileges effectively by modifying system settings that should be protected from lower-level users. This might include disabling security features, altering audit logs to hide malicious activity, or changing configurations that impact network stability. The ability to perform unauthorized updates undermines the principle of least privilege and compromises the trust model inherent in multi-user environments. Since GLPI often manages sensitive IT infrastructure data, such as hardware inventories and service level agreements, any tampering with these records can lead to inaccurate reporting, compliance failures, or operational disruptions that are difficult to trace back to a specific user if logging mechanisms were also affected by the unauthorized changes.
This vulnerability aligns closely with CWE-269, which describes Improper Privilege Control, as it involves an actor obtaining more privileges than intended for their account level. Furthermore, in terms of offensive security frameworks like MITRE ATT&CK, this behavior maps to T1078 Valid Accounts and potentially T1484 Domain Policy Modification if the updates involve changing domain or group policies within the GLPI context. The exploitation path typically requires initial authentication, which may be achieved through credential stuffing, phishing, or theft of existing low-level credentials, followed by crafting specific API requests that target the unprotected endpoints.
To mitigate this risk and prevent similar issues in future development cycles, organizations running affected versions must immediately upgrade to version 11.0.8 or later, where the authorization checks have been corrected to ensure consistent enforcement across all interfaces. For environments unable to patch immediately due to operational constraints, implementing a web application firewall with rules that restrict API access based on user roles can provide an additional layer of defense. Additionally, developers should adopt a security-first approach by centralizing permission validation logic and conducting thorough code reviews focused on authorization checks for every public-facing endpoint. Regular penetration testing that specifically targets privilege escalation via API endpoints is also recommended to identify any remaining gaps in the application's access control model before they can be exploited in production environments.