GLPI EUVD-2026-87289

Requires an authenticated GLPI account holding the READ right on logs (Administration > Logs / historical entries); with that right the attacker crafts a URL for an item's Historical (history) tab and supplies attacker-controlled affected_fields filter values (e.g. itemtype_link) that reach Log::convertFiltersValuesToSqlCriteria unvalidated. Limiting factors: the READ-on-logs privilege is not held by ordinary/self-service users by default, so exploitation is gated to users with elevated log-viewing permission; affects GLPI 9.4.0 up to but not including 10.0.26 and 11.0.8. No user interaction by a victim is needed.

This is a genuine SQL injection (CWE-89) in GLPI's history/logs tab, corroborated by the vendor advisory GHSA-cpcj-x335-5cmh and two fix commits (1296798f, 80b86c0d) that add key allowlisting and itemtype validation in Log::convertFiltersValuesToSqlCriteria - so the vulnerability itself is well-confirmed. The NVD CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:L, 7.1) is internally consistent and credible: remote and low-complexity, but requiring privileges (PR:L) because the attacker must already hold the READ right on logs, which meaningfully narrows the attacker pool to authenticated GLPI users with an elevated permission. Impact is confidentiality-weighted (VC:H = broad database read) with no integrity impact (VI:N, read-only injection into query criteria) and only limited availability (VA:L). No EPSS score, no CISA KEV listing, and no public exploit code are provided in the intelligence, so there is no evidence of active or automated exploitation - this is a real, patch-worthy issue but not an emergency drop-everything item, and its priority should track how many low-trust users have the log READ right. No signals conflict; the main caveat is the missing EPSS/KEV/POC data, whose absence is not itself an error.

An authenticated GLPI user who has been granted the READ right on logs opens an item's Historical tab and manually crafts the filter URL, placing SQL metacharacters into the affected_fields parameters (e.g. the itemtype_link value) that were passed unvalidated into the query. The injected values alter the underlying database query, allowing the attacker to read data beyond their intended scope. No public proof-of-concept is identified in the provided intelligence.