CVE-2026-108726: 
GLPI vulnerability analysis and mitigation

CVE-2026-108726 is a missing authorization vulnerability in GLPI (Gestionnaire Libre de Parc Informatique) affecting all versions through 12.0.0. The flaw exists in ajax/map.php and allows authenticated low-privileged users to query itemtypes they are not permitted to view due to an absent canView() authorization check. It was published on October 11, 2026, with a patch made available the same day. The vulnerability carries a CVSS v3.1 base score of 4.3 (Medium) and a CVSS v4.0 base score of 5.3 (Medium) (Github Advisory, Feedly).

The root cause is CWE-862 (Missing Authorization): the ajax/map.php endpoint processes POST requests containing an itemtype and params field, passing them directly to Search::prepareDatasForSearch(), Search::constructSQL(), and Search::constructData() without first invoking the canView() permission check that would normally gate access to restricted item types (GLPI Source). An attacker with any valid GLPI account can craft a POST request to /ajax/map.php specifying restricted itemtypes such as Contact, Supplier, Contract, or Budget, along with arbitrary search criteria, and receive back match counts, record titles, and geographic coordinates for records within their entity scope. No elevated privileges, special configuration, or user interaction beyond authentication is required (Github Advisory, VulnCheck Advisory).

Successful exploitation allows an authenticated low-privileged user to read sensitive business data — including contact details, supplier information, contract records, and budget data — that they are explicitly not authorized to access within their GLPI entity. The impact is limited to confidentiality (no integrity or availability impact), and is scoped to the attacker's own entity context, reducing the risk of cross-entity data exposure. While lateral movement is not directly enabled, the disclosed information (supplier names, contract titles, geographic coordinates) could support social engineering or further targeted attacks (Github Advisory, Feedly).

There is no public proof-of-concept exploit code and no evidence of in-the-wild exploitation as of the time of publication (Feedly). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog, and NVD SSVC assessment rates exploitation as "none" with non-automatable attack characteristics. The EPSS score is approximately 0.251%, placing it in the 15th percentile for exploitation likelihood (Github Advisory). No threat actor attribution has been reported.

1. Authentication: Log in to the target GLPI instance with any valid low-privileged user account.
2. Identify the vulnerable endpoint: Locate the ajax/map.php endpoint on the GLPI server (e.g., https://glpi.example.com/ajax/map.php).
3. Craft a malicious POST request: Send a POST request to /ajax/map.php with the itemtype parameter set to a restricted type (e.g., Contact, Supplier, Contract, or Budget) and a params field containing valid GLPI search criteria (e.g., {"start":0,"search":""}). Example using curl:

curl -X POST https://glpi.example.com/ajax/map.php \
  -b 'glpi_session=<session_cookie>' \
  -d 'itemtype=Contract&params[start]=0'

4. Parse the JSON response: The server returns a JSON object containing points — an array of map markers with lat, lng, title, loc_id, and count fields corresponding to restricted records the user should not be able to view.
5. Enumerate additional itemtypes: Repeat with other restricted itemtypes to enumerate available sensitive records within the attacker's entity scope (GLPI Source, HackMD Write-up).

• Network: Unusual or repeated POST requests to /ajax/map.php from low-privileged user sessions, particularly with itemtype values of Contact, Supplier, Contract, or Budget; high-frequency requests to this endpoint from a single session may indicate automated enumeration.
• Logs: Web server access logs showing POST requests to ajax/map.php with non-standard itemtype parameters from accounts that do not normally use map features; GLPI application logs showing search queries for itemtypes inconsistent with the user's assigned role.
• Behavioral: A low-privileged user account generating map/search activity against itemtypes outside their normal operational scope, especially in rapid succession across multiple itemtype values.

The primary remediation is to upgrade GLPI to a version beyond 12.0.0 that includes the authorization fix restoring the canView() check in ajax/map.php (Github Advisory, VulnCheck Advisory). As a temporary workaround where upgrading is not immediately possible, administrators can restrict network-level access to the ajax/map.php endpoint via web server configuration (e.g., requiring specific roles or IP allowlisting), or disable the map feature entirely. Reviewing and tightening GLPI user role assignments to minimize the number of accounts with access to the GLPI instance can also reduce exposure.

A technical write-up documenting the vulnerability was published on HackMD by the apparent discoverer (HackMD Write-up). VulnCheck published an advisory cataloguing the issue (VulnCheck Advisory). No significant vendor statements, broader media coverage, or notable community discussion beyond standard vulnerability tracking has been observed.