CVE-2025-24799

What it actually does

This is a critical unauthenticated SQL injection in GLPI's inventory endpoint. A remote attacker can send specially crafted inventory requests that cause attacker-controlled input to be interpreted as SQL by the backend database. Depending on database privileges and configuration, exploitation can allow extraction or modification of GLPI data, authentication bypass through credential/session theft, creation or alteration of application records, and potentially further compromise if database features or application write paths can be abused. Because the vulnerable endpoint is reachable without authentication, internet-exposed GLPI instances are at especially high risk.

Why it matters to the business

Successful exploitation can expose sensitive IT asset inventory, user information, service desk data, credentials or tokens stored in the application, and operational details useful for follow-on attacks. Attackers may also alter tickets, assets, users, or configuration data, disrupting IT operations and reducing trust in the asset-management system. The high CVSS score, weaponized exploit maturity, high EPSS probability, and long time since publication make this a priority issue even though it is not currently listed in CISA KEV.

How an attack unfolds

An attacker first identifies an exposed GLPI instance and confirms the inventory endpoint is reachable without authentication. They then send crafted HTTP requests to that endpoint with malicious values in fields processed by the inventory workflow. If the instance is vulnerable, the backend constructs unsafe SQL using attacker-controlled input, allowing the attacker to infer database behavior through errors, timing differences, or returned application responses. The attacker can then enumerate database structure, extract sensitive tables such as users, sessions, configuration, assets, and ticket data, and potentially modify records if the database account permits writes. Stolen credentials, password hashes, API tokens, or session material may be used to access GLPI legitimately or pivot into connected infrastructure.

How to fix it

Upgrade GLPI to version 10.0.18 or later. For source-based deployments, ensure the application includes the upstream fix at commit 9389461d8a207bdcdf4f50f9db9fc8acdf6c7bbf or a later trusted release. If using packaged builds, update through the vendor package channel and verify the package contains the GLPI security fix; the provided fixed package references include linux-lts Alpaquita 23 fixed in 6.1.151-r0 and Alpaquita stream/25 fixed in 6.12.44-r0, though GLPI application version should still be validated separately. As temporary mitigation, restrict access to the inventory endpoint to trusted inventory agents and networks, place the application behind a WAF or reverse proxy rule that blocks SQL injection patterns, disable unused inventory ingestion if operationally feasible, and ensure the GLPI database user has only the minimum privileges required by the application. Rotate GLPI API tokens, integration credentials, and privileged user passwords if exploitation is suspected.

How to confirm the fix worked

Confirm the running GLPI version is 10.0.18 or later from the application UI, command line, package metadata, or deployed source revision. Verify the vulnerable code path has been updated to include commit 9389461d8a207bdcdf4f50f9db9fc8acdf6c7bbf or a later release. Check that the inventory endpoint is not anonymously reachable from untrusted networks unless explicitly required. Review reverse proxy, web server, and application logs to ensure requests to the inventory endpoint are either limited to expected agent sources or blocked by access controls. If using a vulnerability scanner, run an authenticated or version-aware check and confirm it reports the GLPI instance as fixed. Avoid validating with destructive SQL injection payloads against production systems.

Typical attack path

1. Scan for internet-facing GLPI installations and fingerprint version or exposed inventory functionality.
2. Send unauthenticated requests to the inventory endpoint to determine whether vulnerable SQL behavior is present.
3. Use error-based, boolean-based, or time-based SQL injection techniques to confirm exploitability.
4. Enumerate database metadata and identify GLPI application tables containing users, sessions, assets, configuration, tickets, or credentials.
5. Extract sensitive data such as account details, password hashes, API tokens, session values, inventory records, and operational information.
6. Optionally modify database records, create persistence through application-level accounts or tokens, or use stolen information for lateral movement.

How to detect it

Review HTTP access logs from web servers, reverse proxies, WAFs, and load balancers for unauthenticated requests to GLPI inventory paths, especially requests containing SQL metacharacters, encoded payloads, unusual JSON/XML fields, or high request volume from unfamiliar sources. Look for time-based SQL injection probes that produce long response times, repeated 500 errors, or database error messages following inventory requests. Review GLPI application logs and PHP error logs for SQL syntax errors, exceptions, stack traces, or warnings associated with inventory processing. Review database logs, if enabled, for queries referencing GLPI tables with suspicious constructs such as UNION SELECT, information_schema access, SLEEP, BENCHMARK, comments, or tautologies. Investigate successful logins, new users, new API tokens, privilege changes, deleted logs, asset/ticket modifications, and session activity after suspicious inventory endpoint requests. Correlate source IPs from suspicious requests with later authenticated activity in GLPI or other internal services.

• /front/inventory.php
• inventory.php
• /plugins/fusioninventory/
• UNION SELECT
• UNION ALL SELECT
• information_schema
• SLEEP(
• BENCHMARK(
• WAITFOR DELAY
• SQL syntax
• You have an error in your SQL syntax
• PDOException
• mysqli_sql_exception
• SQLSTATE[
• ' OR '1'='1
• " OR "1"="1
• -- -
• /*
• %27%20OR%20%271%27%3D%271
• %22%20OR%20%221%22%3D%221
• /front/inventory.php?
• POST /front/inventory.php

What your security team should do

• Immediately inventory all GLPI deployments, especially internet-facing instances, and prioritize upgrades to 10.0.18 or later.
• Restrict the inventory endpoint to trusted source IP ranges or authenticated network paths until every instance is confirmed fixed.
• Hunt web, WAF, reverse proxy, and database logs for suspicious unauthenticated requests to the inventory endpoint, SQL error messages, and time-based SQL injection patterns.
• Review GLPI users, API tokens, sessions, automation accounts, and recent administrative changes for unauthorized access or persistence.
• Rotate GLPI API tokens, integration secrets, and privileged credentials if there is any indication of exploitation.
• Apply least-privilege permissions to the GLPI database account and verify it cannot perform unnecessary administrative operations.
• Add SIEM detections for SQL injection keywords and abnormal request patterns targeting GLPI inventory paths.
• Preserve relevant logs before rotation because the vulnerability has been public for a long period and weaponized exploitation is reported.