Reflected cross-site scripting in glpi-project GLPI dashboards

GLPI is a free asset and IT management software package. From 11.0.0 until 11.0.8, an attacker can craft a URL for a dashboard that reflects attacker-controlled markup without sufficient output encoding. A user who opens the crafted URL triggers reflected cross-site scripting in the dashboard. This issue is fixed in version 11.0.8.

• GLPI from glpi-project: versions >= 11.0.0, < 11.0.8 are identified as affected.
• The normalized record identifies 11.0.8 as fixed. The project advisory describes the affected line as starting at 11.0.0 and names 11.0.8 as the patched version; the < 11.0.8 boundary from the affected facts is used for the precise scope in this entry.
• The available evidence does not establish the status of GLPI branches outside this range.

GLPI reflects attacker-controlled markup from a dashboard URL into HTML output without sufficient encoding. The affected component is dashboard rendering, with a corrected sink identified in src/Glpi/Dashboard/Widget.php, in articleList. The patch passes $p['alt'] through \htmlescape() before inserting it into the HTML title attribute, showing that the issue involves placing controllable data into web-page output. The attack requires a victim to open a crafted URL; the complete set of request parameters, the precise JavaScript execution context, and the scope of any other affected sinks are not established by the available evidence.

The vulnerability is reachable over the network, and the record states that the attacker does not need prior privileges and faces low complexity, but an active user must open the crafted URL. This is consistent with reflected XSS in a dashboard, where the payload is carried in the URL and reflected when the page loads. The record does not establish observed exploitation; public_exploit is false, while known exploitation status is not established.

Successful exploitation can cause attacker-controlled script to execute in a GLPI user's browser, potentially reading data available to that user or sending requests with the user's permissions. The practical outcome depends on the victim's privileges, session state, and additional browser or application protections. The record characterizes the vulnerable system impact as high for confidentiality, integrity, and availability, but it does not establish impact to subsequent systems or server-side code execution. The flaw should not be treated as evidence of server compromise without independent supporting evidence.

• A user who opens a malicious URL may cause attacker-controlled script to run in the GLPI browser context.
• Depending on the user's permissions and accessible data, the result could include exposure of information available in the session, actions performed with the user's permissions, or disruption of the interface and related workflows.
• The operational risk is greatest for GLPI instances used by administrators or users handling sensitive asset and IT-management data through dashboards.
• The available evidence does not identify a victim, campaign, breach, or affected organization.

1. Upgrade GLPI to 11.0.8, the confirmed patched release identified by the project advisory.
2. Verify the actual deployed version after the change, including secondary instances, container images, manual installations, and staging environments that may later be promoted to production.
3. If an upgrade cannot be completed immediately, treat instances in the affected range as exposed. The available evidence does not provide a vendor-specific workaround, so generic WAF filtering or other compensating controls should not be treated as a confirmed fix.

• Inventory deployed GLPI systems and identify the version of each instance, prioritizing instances that expose dashboards to users.
• Where source is available, inspect src/Glpi/Dashboard/Widget.php and articleList to confirm that controllable values are encoded before entering HTML output.
• As a precaution, review access or proxy logs for dashboard requests containing markup-like or unusually encoded URL values. This is not a vendor-confirmed indicator of compromise.
• Do not treat the absence of suspicious log entries as proof of safety, because reflected XSS may not produce a distinctive server-side log record.