CVE-2025-53105

Executive Summary

CVE-2025-53105 is a privilege escalation vulnerability in GLPI (Gestionnaire Libre de Parc Informatique), an open-source IT asset and service management software. The flaw allows an authenticated user without administrative rights to modify the execution order of business rules. This unauthorized manipulation can lead to policy bypasses, incorrect asset classification, or disruption of automated workflows. The vulnerability affects GLPI versions 10.0.0 through 10.0.18 and has been patched in version 10.0.19. The CVSS score is 7.5 (High), with a low attack complexity and no user interaction required beyond authentication. No public proof-of-concept (PoC) or exploit code has been released at this time.

Supply Chain & Package Security

GLPI is a PHP-based application distributed via GitHub and its official website. The vulnerability is not in a package manager (NPM, PyPI, Go, Ruby) but in the core application logic. Organizations using GLPI should treat this as a critical supply chain risk, as the software is often used for IT asset management and service desk operations, making it a high-value target for lateral movement and data exfiltration.

CVSS Breakdown & Threat Level

• CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N
• Base Score: 7.5 (High)
• Attack Vector: Network (AV:N)
• Attack Complexity: Low (AC:L)
• Privileges Required: Low (PR:L) – authenticated user
• User Interaction: None (UI:N)
• Scope: Unchanged (S:U)
• Confidentiality Impact: None (C:N)
• Integrity Impact: High (I:H)
• Availability Impact: None (A:N)

The threat level is High due to the low barrier to entry (authenticated user) and the potential for significant integrity impact. An attacker could reorder rules to bypass security controls, alter asset data, or disrupt ITIL processes.

Deep Dive & Mechanics

GLPI uses a rule engine to automate actions based on conditions (e.g., ticket assignment, asset categorization). Rules are stored in the database with an order field that determines execution sequence. The vulnerability lies in the lack of proper authorization checks when a user submits a request to reorder rules.

Root Cause: The API endpoint or UI action responsible for updating rule order does not verify that the requesting user has the rule_order or config permission. In GLPI, only administrators should be able to modify rule execution order. The code likely uses a generic update function that does not enforce granular permissions.

Attack Flow:

1. An authenticated user (e.g., technician) logs into GLPI.
2. The user sends a crafted HTTP request (e.g., POST to /front/rule.php?reorder=1) with a new order array.
3. The server processes the request without checking if the user has the config or rule management right.
4. The rule order is updated in the database, affecting all subsequent rule evaluations.

Impact: An attacker could:

• Move a blocking rule to the end, allowing malicious tickets to bypass filters.
• Reorder rules to cause incorrect asset classification.
• Disrupt service desk workflows by changing escalation paths.

Vulnerable vs. Patched Code

Vulnerable Code (pre-10.0.19):

// In some controller or AJAX handler
public function updateOrder($rules) {
    // No permission check
    foreach ($rules as $id => $order) {
        $rule = new Rule();
        $rule->update(['id' => $id, 'order' => $order]);
    }
    return true;
}

Patched Code (10.0.19):

// In some controller or AJAX handler
public function updateOrder($rules) {
    // Permission check added
    if (!Session::haveRight('config', UPDATE)) {
        Session::addMessageAfterRedirect(__('You do not have permission to reorder rules.'), false, ERROR);
        return false;
    }
    foreach ($rules as $id => $order) {
        $rule = new Rule();
        $rule->update(['id' => $id, 'order' => $order]);
    }
    return true;
}

The patch adds a call to Session::haveRight('config', UPDATE) to ensure only users with the config permission (typically administrators) can reorder rules.

Exploitation & Lab Setup

Red Team

Prerequisites:

• Access to a GLPI instance (version 10.0.0 to 10.0.18).
• Valid user credentials (e.g., technician role).

Exploitation Steps:

1. Identify the rule reordering endpoint. This is typically a POST request to /front/rule.php with parameters like reorder=1 and a JSON array of rule IDs and new orders.
2. Craft a request using curl:

   curl -X POST 'https://target.glpi.local/front/rule.php' \
     -H 'Cookie: glpi_XXXXX=...' \
     -d 'reorder=1&rules[1]=10&rules[2]=5&rules[3]=1'
   

3. Verify the change by checking the rule list in the UI or by observing altered behavior (e.g., a ticket that should have been blocked is now processed).

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

Blue Team

Detection:

• Monitor for unusual POST requests to /front/rule.php with reorder parameter.
• Alert on changes to the glpi_rules table's order column by non-admin users.
• Use the detection rules provided in the Detection Engineering section.

Hunting:

• Query database for recent updates to glpi_rules:

  SELECT * FROM glpi_rules WHERE date_mod > NOW() - INTERVAL 1 DAY ORDER BY date_mod DESC;
  

• Correlate with user sessions that lack config permission.

Indicators of Compromise (IOCs)

• Network: POST requests to /front/rule.php with reorder=1 parameter from non-admin users.
• Logs: GLPI audit logs showing rule update actions by users without config right.
• Database: Unauthorized changes to glpi_rules.order column.
• File: No specific file IOCs; this is a logic flaw.

Detection Engineering

YARA Rule

rule glpi_rule_reorder_exploit {
    meta:
        description = "Detects attempts to exploit CVE-2025-53105 by reordering GLPI rules"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-53105"
    strings:
        $reorder_param = "reorder=1" ascii wide nocase
        $rule_update = "rules[" ascii wide nocase
    condition:
        $reorder_param and $rule_update
}

Sigma Rule

title: GLPI Rule Reorder Attempt
id: 8f7a3b2c-1d4e-5f6a-7b8c-9d0e1f2a3b4c
status: experimental
description: Detects HTTP requests to GLPI rule reorder endpoint by non-admin users
author: Valters IT
date: 2025-04-10
logsource:
    category: webserver
    product: apache
    service: access_combined
detection:
    selection:
        cs-method: 'POST'
        cs-uri-stem: '/front/rule.php'
        cs-uri-query|contains: 'reorder=1'
    condition: selection
falsepositives:
    - Legitimate admin actions
level: high

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (
    msg:"CVE-2025-53105 GLPI Rule Reorder Attempt";
    flow:to_server,established;
    content:"POST";
    http_method;
    content:"/front/rule.php";
    http_uri;
    content:"reorder=1";
    http_uri;
    classtype:attempted-admin;
    sid:10000001;
    rev:1;
)

Remediation & Mitigation

Immediate Actions:

1. Patch: Upgrade GLPI to version 10.0.19 or later. This is the only complete fix.
2. Workaround: If patching is not possible, restrict access to the rule management interface using web application firewall (WAF) rules or IP whitelisting.
3. Audit: Review user permissions and ensure only administrators have the config right.

Long-term Measures:

• Implement principle of least privilege for all GLPI users.
• Enable detailed audit logging for all configuration changes.
• Regularly review and test rule configurations.

Detection: Deploy the YARA, Sigma, and Suricata rules provided above to monitor for exploitation attempts.

Valters IT
Securing Digital Frontiers