CVE-2026-53629: 
GLPI vulnerability analysis and mitigation

CVE-2026-53629 is a SQL injection vulnerability in GLPI (Gestionnaire Libre de Parc Informatique), a free asset and IT management software package. An authenticated attacker with READ rights on logs can craft a malicious URL targeting the history tab endpoint to inject attacker-controlled values into a database query. The vulnerability affects GLPI versions from 9.4.0 up to (but not including) 10.0.26, and versions 11.0.0 up to (but not including) 11.0.8. It was disclosed on July 27, 2026 via a GitHub Security Advisory and carries a CVSS v4.0 base score of 7.1 (High) (GitHub Advisory, GLPI Release 10.0.26).

The root cause is improper neutralization of special elements in an SQL command (CWE-89), specifically in the convertFiltersValuesToSqlCriteria() function within src/Log.php. The vulnerable code failed to validate or allowlist the key component of the filter[affected_fields][] parameter before incorporating it into a database query, allowing arbitrary SQL to be injected via the front/log/export.php endpoint. The fix introduced an allowlist of permitted keys (linked_action, id_search_option, itemtype_link) and added validation of itemtype_link values against known GLPI item types, preventing injection of arbitrary SQL fragments (GitHub Advisory, Patch Commit 10.x, Patch Commit 11.x). A public PoC exploit (glpi_sqli_extract.py) demonstrates time-based blind SQL injection against this endpoint (PoC GitHub).

Successful exploitation allows an authenticated attacker to read sensitive data from the GLPI database beyond their authorization level, including password hashes and API tokens from the glpi_users table. The primary impact is high confidentiality loss, with low availability impact due to the resource consumption of time-based injection queries; integrity is not directly affected. Extracted password hashes can be cracked offline or used for horizontal/vertical privilege escalation within GLPI and potentially the broader infrastructure (GitHub Advisory, PoC GitHub).

A functional proof-of-concept Python exploit (glpi_sqli_extract.py) is publicly available on GitHub, implementing time-based blind SQL injection to extract password hashes character-by-character from the glpi_users table (PoC GitHub). The vulnerability requires authentication with READ rights on logs, making it a post-authentication escalation vector rather than an unauthenticated attack. The EPSS score is approximately 0.0102 (low probability of near-term exploitation), and there is no evidence of in-the-wild exploitation or CISA KEV catalog listing as of the time of reporting. A Nuclei detection template was also added to ProjectDiscovery's template library, increasing automated scanning potential (Feedly).

1. Reconnaissance: Identify GLPI instances running versions 9.4.0–10.0.25 or 11.0.0–11.0.7 using Shodan, Censys, or web application fingerprinting. Confirm the version from the GLPI login page or HTTP headers.
2. Obtain credentials: Acquire valid GLPI credentials for an account with READ rights on logs (e.g., a low-privileged read-only account).
3. Extract CSRF token: Send a GET request to /front/login.php and parse the _glpi_csrf_token value from the HTML response.
4. Authenticate: Send a POST request to /front/login.php with login_name, login_password, and the CSRF token; follow redirects to establish an authenticated session.
5. Verify injection: Send a GET request to /front/log/export.php with parameters itemtype=Entity, id=0, and filter[affected_fields][0]='OR::(SELECT CASE WHEN 1 AND sleep(1) THEN sleep(0.1) ELSE 0 END)'; confirm the response time exceeds 0.5 seconds to validate the injection point.
6. Determine data length: Use binary search with payloads like (SELECT LENGTH(password) FROM glpi_users WHERE id=N)>=i combined with sleep() to determine the exact length of the target field.
7. Extract data character-by-character: For each character position, inject ORD(MID(query FROM pos FOR 1))>mid conditions with binary search over ASCII values (32–126), inferring each character from response timing.
8. Crack or use extracted hash: Output the reconstructed password hash from glpi_users.password, then crack it offline or use it for further privilege escalation (PoC GitHub, GitHub Advisory).

• Network: Repeated HTTP GET requests to /front/log/export.php with filter[affected_fields][] parameters containing SQL keywords such as sleep, SELECT, CASE, WHEN, OR, MID, or ORD; unusual response time patterns (consistent delays of ~1 second) from the GLPI web server suggesting time-based injection.
• Logs: GLPI web server access logs showing multiple requests to /front/log/export.php with encoded or unusual query strings in the filter[affected_fields] parameter from a single authenticated user; sequences of near-identical requests differing only in numeric values (indicative of binary search enumeration).
• Application Behavior: Elevated database query execution times correlated with requests to the log export endpoint; database slow query logs showing repeated SLEEP() or BENCHMARK() calls originating from the GLPI application user.
• Process: Unexpected spikes in database CPU or connection count coinciding with log export endpoint activity (PoC GitHub).

Upgrade GLPI to version 10.0.26 (for the 10.0.x branch) or 11.0.8 (for the 11.0.x branch), both released on June 24, 2026, which include the fix for this vulnerability (GLPI Release 10.0.26, GLPI Release 11.0.8). As an interim workaround, remove the READ right on logs from all non-administrator accounts to eliminate the attack surface until patching can be completed (GitHub Advisory). Organizations should also audit which accounts currently hold log READ permissions and restrict them to the minimum necessary set of trusted administrators.

The vulnerability was reported by security researcher 5kr1pt, who also co-authored the patch and published the proof-of-concept exploit on GitHub (GitHub Advisory, PoC GitHub). The GLPI project forum acknowledged the release as a security update and recommended upgrading (GLPI Forum). The vulnerability was also picked up by threat intelligence aggregators and a Nuclei detection template was added to ProjectDiscovery's template library, indicating moderate community interest in automated detection.