CVE-2024-43416: GLPI Information Disclosure Vulnerability

CVE-2024-43416 Overview

GLPI is a free asset and IT management software package used by organizations to track infrastructure, tickets, and users. CVE-2024-43416 is an information disclosure vulnerability affecting GLPI versions from 0.80 up to (but not including) 10.0.17. An unauthenticated attacker can query an application endpoint to determine whether a supplied email address corresponds to a valid GLPI user account. The flaw is categorized under [CWE-200] (Exposure of Sensitive Information to an Unauthorized Actor). Version 10.0.17 resolves the issue.

Critical Impact
Remote, unauthenticated attackers can enumerate valid GLPI account email addresses, enabling targeted phishing, credential stuffing, and account takeover preparation.

Affected Products

GLPI versions >= 0.80 and < 10.0.17
GLPI forgot-password / password-reset endpoint (src/User.php)
Deployments exposing the GLPI web front-end to untrusted networks

Discovery Timeline

2024-11-18 - CVE-2024-43416 published to the National Vulnerability Database (NVD)
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2024-43416

Vulnerability Analysis

The vulnerability resides in the forgot-password workflow implemented in src/User.php. When a user requests a password reset, GLPI looks up the submitted email address in the user database. If a match exists, the application dispatches a notification email through Simple Mail Transfer Protocol (SMTP). If no match exists, no email is sent.

The difference in server-side processing produces an observable timing discrepancy. Sending an SMTP notification takes measurably longer than skipping the operation. An unauthenticated attacker can time responses to the reset endpoint and infer whether a submitted email belongs to a valid GLPI user. This qualifies as a side-channel information disclosure and enables mass enumeration of the user base.

Root Cause

The forgot-password handler did not normalize response time between the "user found" and "user not found" branches. The SMTP send in the positive branch introduces a latency signal that leaks account existence. Prior to 10.0.17, the code path also lacked rate limiting on the reset endpoint, allowing high-volume probing.

Attack Vector

The attack is network-based, requires no authentication, and needs no user interaction. An attacker submits candidate email addresses (for example, harvested from LinkedIn, breach corpora, or common formats such as first.last@company.tld) to the password-reset endpoint and measures response latency. Consistent longer responses indicate a valid GLPI account. The confirmed accounts are then used as seeds for spear-phishing, credential stuffing, or password-spray campaigns against the GLPI login and any single sign-on system it federates with.

php

            ]
        ];

+        // Randomly increase the response time to prevent an attacker to be able to detect whether
+        // a notification was sent (a longer response time could correspond to a SMTP operation).
+        sleep(rand(1, 3));
+
        // Try to find a single user matching the given email
        if (!$this->getFromDBbyEmail($email, $condition)) {
            $count = self::countUsersByEmail($email, $condition);

Source: GLPI commit 9be1466053f829680db318f7e7e5880d2d789c6d. The patch injects a randomized sleep(rand(1, 3)) before the email lookup so the total response time no longer discloses whether a notification was dispatched.

Detection Methods for CVE-2024-43416

Indicators of Compromise

High volume of POST requests to the GLPI forgot-password endpoint from a single source or a small set of sources
Sequential submissions of email addresses following predictable naming patterns
Web-server access logs showing bursty traffic to /front/lostpassword.php or equivalent reset routes
Follow-on phishing emails referencing legitimate GLPI usernames or ticket workflows

Detection Strategies

Alert on unauthenticated requests to the password-reset endpoint exceeding a defined baseline per source IP over short windows
Correlate reset-endpoint traffic with response-time distributions to identify probing behavior
Fingerprint enumeration tooling by inspecting User-Agent strings, TLS JA3 hashes, and request cadence

Monitoring Recommendations

Forward GLPI web-server and application logs to a centralized analytics platform for long-window analysis
Track the ratio of password-reset requests to successful password resets; enumeration campaigns skew this ratio heavily
Monitor downstream authentication systems (SSO, Active Directory) for spikes in failed logins tied to email addresses first probed against GLPI

How to Mitigate CVE-2024-43416

Immediate Actions Required

Upgrade GLPI to version 10.0.17 or later on all production and staging instances
Restrict access to the GLPI web interface to trusted networks or place it behind a VPN where feasible
Enable a web application firewall (WAF) rule set to rate-limit and challenge unauthenticated requests to the password-reset endpoint
Rotate credentials and force password resets for any accounts you suspect were enumerated and subsequently targeted

Patch Information

GLPI 10.0.17 contains the fix. The remediation is tracked in the GitHub Security Advisory GHSA-j8gc-xpgr-2ww7 and implemented in the GLPI upstream commit. The patch introduces a randomized delay so response timing no longer reveals whether an SMTP notification was sent.

Workarounds

Place the GLPI reset endpoint behind an authenticated reverse proxy or Single Sign-On (SSO) gateway until patching is complete
Configure WAF or reverse-proxy rate limits (for example, 5 requests per minute per source IP) on the reset URL
Add an artificial randomized delay at the reverse-proxy layer to blur timing side channels
Deploy CAPTCHA or proof-of-work challenges on the password-reset form for unauthenticated users

bash

# NGINX rate limit example for the GLPI password-reset endpoint
http {
    limit_req_zone $binary_remote_addr zone=glpi_reset:10m rate=5r/m;

    server {
        location = /front/lostpassword.php {
            limit_req zone=glpi_reset burst=3 nodelay;
            proxy_pass http://glpi_backend;
        }
    }
}