CVE-2026-53628: GLPI Authentication Bypass Vulnerability

CVE-2026-53628 Overview

GLPI is a free IT asset and service management platform used widely for help-desk, inventory, and user administration. CVE-2026-53628 describes an authorization flaw in the user administration workflow. An administrator holding the Update auth and sync or Update auth, sync and 2FA right can change the authentication method and disable two-factor authentication (2FA) on user accounts that sit outside the administrator's entity scope. The affected flow did not consistently enforce the target user's entity-scoped update permission [CWE-285]. The issue is fixed in GLPI versions 10.0.26 and 11.0.8.

Critical Impact
An administrator restricted to one entity can tamper with authentication settings and remove 2FA from users in other entities, enabling account takeover across tenant boundaries.

Affected Products

GLPI from version 0.84 up to and including 10.0.25
GLPI 11.x up to and including 11.0.7
Fixed in GLPI 10.0.26 and 11.0.8

Discovery Timeline

2026-09-25 - CVE-2026-53628 published to the National Vulnerability Database (NVD)
2026-09-30 - Last updated in NVD database

Technical Details for CVE-2026-53628

Vulnerability Analysis

GLPI implements multi-tenancy through entities, and administrative rights are supposed to be scoped to the entities a user manages. The user administration flow checked only that the acting session held the UPDATEAUTHENT right, but did not verify that the target user record was within the administrator's entity scope. As a result, an entity-scoped administrator could invoke actions such as LDAP resynchronization, LDAP field cleanup, authentication method changes, and 2FA toggles against user accounts belonging to other entities.

The practical consequence is cross-entity tampering with authentication state. Disabling 2FA on a privileged account in another entity removes a key control and increases the likelihood of downstream account takeover. The flaw is a classic broken access control pattern where authentication is enforced but object-level authorization is missing.

Root Cause

The root cause is missing object-level authorization in front/user.form.php and in src/Auth.php. The code called Session::checkRight('user', User::UPDATEAUTHENT) to validate the acting user's global capability, but never called the per-object check() or can() method against the target User record. Entity boundaries, which are enforced through the per-object check, were therefore never evaluated for these actions.

Attack Vector

Exploitation requires an authenticated administrator with the UPDATEAUTHENT right in at least one entity. The attacker submits POST requests to front/user.form.php with parameters such as force_ldap_resynch or clean_ldap_fields, or invokes the synchronization form rendered by Auth::showSynchronizationForm(), passing the id of a target user in a different entity. The server performs the requested authentication change without rejecting the out-of-scope target.

php

// Patch excerpt: front/user.form.php
$user->redirectToList();
} elseif (isset($_POST["force_ldap_resynch"])) {
    Session::checkRight('user', User::UPDATEAUTHENT);
+   $user->check($_POST['id'], UPDATE);

    $user->getFromDB($_POST["id"]);
    AuthLDAP::forceOneUserSynchronization($user);
    Html::back();
} elseif (isset($_POST["clean_ldap_fields"])) {
    Session::checkRight('user', User::UPDATEAUTHENT);
+   $user->check($_POST['id'], UPDATE);

    $user->getFromDB($_POST["id"]);
    AuthLDAP::forceOneUserSynchronization($user, true);

Source: GitHub Commit 27cc088

php

// Patch excerpt: src/Auth.php - showSynchronizationForm()
public static function showSynchronizationForm(User $user)
{
-   if (Session::haveRight("user", User::UPDATEAUTHENT)) {
+   if (Session::haveRight("user", User::UPDATEAUTHENT) && $user->can($user->getID(), READ)) {
        TemplateRenderer::getInstance()->display('pages/setup/authentication/sync.html.twig', [
            'user' => $user,
        ]);

Source: GitHub Commit f06a790

The fix adds $user->check($_POST['id'], UPDATE) and $user->can($user->getID(), READ) to enforce entity-scoped access on the target record.

Detection Methods for CVE-2026-53628

Indicators of Compromise

POST requests to front/user.form.php containing force_ldap_resynch, clean_ldap_fields, or authentication-change parameters targeting user IDs outside the acting administrator's entity.
Unexpected changes to the authtype, auths_id, or 2FA fields in the glpi_users table, especially for privileged accounts.
Audit log entries showing authentication method modifications or 2FA deactivations performed by non-super-admin accounts.

Detection Strategies

Review the GLPI historical log (glpi_logs) for User item changes to authtype and 2FA attributes, correlating the acting user's entity with the target user's entity.
Inspect web server access logs for POSTs to /front/user.form.php and /front/user.form.php?...sync originating from accounts that should not administer the target entities.
Baseline normal admin behavior per entity, then alert on administrators that touch users outside their assigned entities.

Monitoring Recommendations

Enable and centrally forward GLPI application and web server logs to a SIEM or data lake for correlation.
Alert when 2FA is disabled on any account tagged as privileged or service-critical.
Monitor for repeated LDAP resynchronization requests against varied user IDs, which can indicate scripted abuse of this flaw.

How to Mitigate CVE-2026-53628

Immediate Actions Required

Upgrade GLPI to 10.0.26 or 11.0.8 as soon as possible.
Audit all accounts holding the Update auth and sync or Update auth, sync and 2FA rights and remove the privilege where it is not strictly required.
Review the glpi_logs and glpi_users tables for recent authentication-method or 2FA changes performed by entity-scoped administrators, and reset credentials or re-enable 2FA where tampering is suspected.

Patch Information

The GLPI project released fixes in versions 10.0.26 and 11.0.8. The patches add target-object authorization checks to the LDAP resync, LDAP field cleanup, and synchronization-form flows. See GitHub Security Advisory GHSA-2hf7-pw75-7wcp, GitHub Release v10.0.26, and GitHub Release v11.0.8.

Workarounds

Restrict the UPDATEAUTHENT right to a small set of super-administrators that already have full entity scope.
Enforce multi-factor authentication at the identity provider or reverse proxy so that disabling GLPI-native 2FA does not fully remove a second factor.
Place the GLPI administration interface behind network segmentation or VPN access to reduce exposure to compromised internal accounts.

bash

# Verify the installed GLPI version and plan an upgrade
php bin/console --version
# Expected output after patching:
# GLPI CLI 10.0.26  (or 11.0.8)

# Example upgrade sequence (adapt paths to your deployment)
cd /var/www/glpi
php bin/console glpi:maintenance:enable
# Replace sources with 10.0.26 or 11.0.8 release archive, then:
php bin/console db:update --allow-unstable
php bin/console glpi:maintenance:disable