GLPI is a popular open-source IT asset and service management tool that’s especially favored by sysadmins in businesses and schools. Security is key for any software that holds sensitive IT data, and unfortunately, a recent vulnerability exposes many GLPI installations to unauthorized access — even if you thought you were locked down.
This long read explains CVE-2025-23046, found in the OauthIMAP plugin for GLPI’s authentication module. We’ll walk through how this bug works, show you code snippets, link to references, and let you know how you can protect yourself.
What’s CVE-2025-23046?
Vulnerability summary:
Starting from GLPI version 9.5. and up to, but not including, 10..18, if you’re using a "Mail servers" authentication provider with Oauth (through the OauthIMAP plugin), any attacker who can provide a valid user name with an existing Oauth authorization can log into GLPI — even if they never had a GLPI account before, or had authorization revoked!
Risk:
An attacker can gain access to your GLPI instance as any user with an established Oauth authorization. This means data exposure, possible privilege escalation, and loss of control over your IT assets.
Let’s break it down in simple terms.
- OauthIMAP is a plugin that lets GLPI authenticate users by accessing their mail server via Oauth (popular for things like Gmail, Microsoft 365).
- Once a user’s Oauth authorization is established, GLPI can let them in during future logins by verifying through Oauth.
- Unfortunately, due to a flaw, GLPI doesn't verify whether this Oauth-authenticated user actually *should* have GLPI access.
- So, if an attacker can obtain an Oauth token for a legit user’s email, they can log in as that user.
Employee “Alice” uses Gmail and has OauthIMAP enabled.
3. Attacker gets an Oauth authorization for Alice’s email (maybe Alice’s login is authorized on a shared machine, or token “leaks”).
4. Attacker uses Alice’s email as the user, authenticates via Oauth, and GLPI gives attacker Alice’s access.
5. Even if IT disables Alice in GLPI, as long as Oauth access exists, the attacker can keep logging in.
Code Insights
Let’s look at a simplified bit of PHP logic related to OauthIMAP authentication (note: this is an illustrative example, not a direct source line):
$user_email = $_POST['login'];
$oauth_token = $_POST['oauth_token'];
// OauthIMAP verifies the token and email
if (OauthIMAP::verify($user_email, $oauth_token)) {
// GLPI automatically creates or re-enables the user session
$user = GLPIUser::findOrCreate($user_email);
$_SESSION['user'] = $user;
}
What’s Wrong Above?
There’s not enough checking that this user is still *allowed* in GLPI. The verification stops at "Oauth says they're good," so attackers can ride in once they gain an Oauth token — regardless of the intended user access controls.
What Can an Attacker Do?
- Login: Use any established Oauth authorization (email+token) to enter GLPI as that email’s owner.
Privilege Escalation: If the hijacked user is an admin, the attacker has wide access.
- Persistency: Even after disabling accounts in GLPI, access persists through Oauth—unless tokens are revoked on the mail provider's side.
💡 Original CVE Entry:
🔗 GLPI Security Advisory:
GitHub Security Advisory for CVE-2025-23046 *(Replace with official link when available)*
🛠️ GLPI Release Notes 10..18:
🧩 OauthIMAP Plugin Info:
The Patch and Workarounds
Patched in:
GLPI 10..18 and later.
Fix details:
GLPI now better checks if the Oauth-authenticated user is permitted to log in, blocking unauthorized or deleted accounts.
For providers using OauthIMAP, disable or delete them.
# For advanced users (CLI/database example, not for production use!)
UPDATE glpi_authmailservers
SET is_active=
WHERE authentication_type='OAuthIMAP';
Conclusion
CVE-2025-23046 is a serious vulnerability for anyone using the OauthIMAP plugin in GLPI versions between 9.5. and 10..18. It allows anyone with a valid Oauth token to access your IT management panel, possibly exposing your entire infrastructure.
Stay safe, share with your IT team, and check your user access controls!
Exclusive security news @YourInfosecNews
*(You won’t find this explained simpler anywhere else!)*
Timeline
Published on: 02/25/2025 18:15:27 UTC
Last modified on: 02/28/2025 14:54:50 UTC