GLPI (Gestionnaire Libre de Parc Informatique) is a popular free and open-source IT Asset Management and Service Desk solution. Organizations worldwide use it to manage hardware, software inventory, tickets, and more. In 2022, a critical vulnerability was found. This issue, tracked as CVE-2022-39234, meant that users whose accounts had been deleted or deactivated could still access sensitive areas if they held a valid session cookie. Below, we break down what happened, why it mattered, and show steps for demonstrating the flaw.

What Happened?

GLPI admins can deactivate or delete user accounts to prevent further system access. However, due to a logic flaw, once-issued sessions (typically managed with browser cookies) were not invalidated immediately when the account status changed. As a result, someone with a valid cookie could continue using the web app, _even after being kicked or deleted_.

Patched: October 2022 (GLPI version 10..4)

- Reference: GitHub Security Advisory GHSA-f8wq-v85r-w89j

Why It’s Bad

1. Continued access for fired or malicious staff – Organizations disable user accounts to maintain security. If those users can still access the system, sensitive company or customer information is at risk.

How the Vulnerability Works

The GLPI login process issues a secure cookie once you log in. That cookie “proves” your session. Here’s the core issue: GLPI didn’t check account status on every request. It just checked the session. If the session was valid, the request went through—even if the backend user was now inactive or deleted.

Try to keep using GLPI, opening new pages or creating tickets.

Result: You’ll notice you can still move around and use the system, _even though you’ve been kicked out in the backend!_ The only way your access ends is if:

curl -b "glpi_session=SESSIONVALUE" https://glpi.example.com/front/ticket.form.php

If the site loads and lets you perform actions, the bug is confirmed.

Below is a conceptualized (not actual GLPI code) snippet showing the security flaw

// Flawed logic: Only session checked
if (isset($_SESSION['user_id'])) {
    // Session valid, proceed
    showDashboard();
} else {
    // No session, redirect to login
    login();
}

Missing: Checking the user’s current status in the database

if (isset($_SESSION['user_id'])) {
    $user = getUserFromDatabase($_SESSION['user_id']);
    if ($user->active) {
        showDashboard();
    } else {
        session_destroy();
        loginMessage("User is inactive or deleted");
    }
}

How Was It Fixed?

GLPI version 10..4 patched this bug. Now, each request checks the account’s “active” status. If you’re deactivated or deleted, any session is killed immediately.

Patch Reference: Diff of the relevant commit

What Should You Do?

Upgrade to GLPI version 10..4 or later.  
There are no effective workarounds—older versions remain vulnerable.

- Official Release Note
- GHSA advisory page
- NVD entry for CVE-2022-39234

Final Thoughts

CVE-2022-39234 is a reminder that log off doesn’t mean access off unless your software actually checks both session and user status every time. It’s a textbook example of how simple logic gaps create real-world risks, especially in enterprise asset and helpdesk systems.

Do you use GLPI? Check your version now—and patch if you haven’t already!

References

- GLPI GitHub Security Advisory: GHSA-f8wq-v85r-w89j
- GLPI Releases
- CVE-2022-39234 at NVD

Timeline

Published on: 11/03/2022 14:15:00 UTC
Last modified on: 11/04/2022 02:54:00 UTC