CVE-2025-53357

Executive Summary

CVE-2025-53357 is an authorization bypass vulnerability in GLPI (Gestionnaire Libre de Parc Informatique), a popular open-source IT asset management software. The flaw allows an authenticated user to modify or delete reservations belonging to other users. This is a classic case of Insecure Direct Object Reference (IDOR), where the application fails to verify that the user performing the action is the owner of the reservation resource. The vulnerability affects GLPI versions 0.78 through 10.0.18 and has been patched in version 10.0.19. While the CVSS score is moderate (5.4), the impact on data integrity and availability within an organization's IT asset management system can be significant, potentially leading to scheduling conflicts and resource mismanagement.

Supply Chain & Package Security

GLPI is a PHP-based application distributed as a standalone package. This vulnerability does not directly affect a package manager (NPM, PyPI, Go, Ruby) but is a core application logic flaw. Users should ensure they are obtaining the patched version (10.0.19) from the official GLPI website or GitHub repository to avoid supply chain risks.

CVSS Breakdown & Threat Level

• CVSS Score: 5.4 (Medium)
• Attack Vector (AV): Network (N) - The vulnerability can be exploited remotely.
• Attack Complexity (AC): Low (L) - No special conditions are required for exploitation.
• Privileges Required (PR): Low (L) - An attacker needs a valid user account.
• User Interaction (UI): None (N) - No user interaction is required.
• Scope (S): Unchanged (U) - The vulnerability does not affect other components.
• Confidentiality (C): None (N) - The vulnerability does not directly expose data.
• Integrity (I): Low (L) - The attacker can modify reservation data.
• Availability (A): Low (L) - The attacker can delete reservations, impacting availability.

Threat Level: Medium. The requirement for authentication reduces the attack surface, but the potential for internal disruption is significant.

Deep Dive & Mechanics

The vulnerability lies in the reservation management module of GLPI. When a user creates, modifies, or deletes a reservation, the application uses a unique identifier (likely an id parameter in the URL or POST data) to identify the target reservation. The flaw is that the application does not verify that the authenticated user is the owner of the reservation associated with that identifier.

Attack Flow:

1. An authenticated user logs into GLPI.
2. The user navigates to the reservation management section.
3. The user intercepts a request (e.g., using a proxy like Burp Suite) to modify or delete a reservation.
4. The user changes the id parameter in the request to a value belonging to another user's reservation.
5. The server processes the request without checking ownership, thus altering or deleting the other user's reservation.

This is a classic IDOR vulnerability (CWE-639). The application relies on the client to provide the correct identifier but fails to enforce server-side authorization checks.

Vulnerable vs. Patched Code

The vulnerable code likely resides in a PHP file handling reservation actions (e.g., front/reservation.php or inc/reservation.class.php). The vulnerable version would look something like this:

Vulnerable Code (Conceptual):

// Vulnerable: No ownership check
$reservation_id = $_POST['id'];
$reservation = new Reservation();
$reservation->getFromDB($reservation_id);
$reservation->update($_POST); // or delete()

Patched Code (Conceptual):

// Patched: Ownership check added
$reservation_id = $_POST['id'];
$reservation = new Reservation();
$reservation->getFromDB($reservation_id);

// Check if the current user is the owner
if ($reservation->fields['users_id'] != Session::getLoginUserID()) {
    Session::addMessageAfterRedirect(__('You are not allowed to modify this reservation.'), false, ERROR);
    Html::back();
}

$reservation->update($_POST);

The patched version adds a check to ensure the users_id field of the reservation matches the currently logged-in user's ID before allowing the update or deletion.

Exploitation & Lab Setup

Red Team (Exploitation)

Prerequisites:

• A valid user account on a vulnerable GLPI instance (versions 0.78 to 10.0.18).
• A web proxy (e.g., Burp Suite, OWASP ZAP) to intercept and modify requests.

Exploitation Steps:

1. Log in to GLPI with a valid user account.
2. Navigate to the reservation management section (e.g., /front/reservation.php).
3. Create a test reservation to understand the request format.
4. Intercept the request to modify or delete a reservation.
5. Change the id parameter in the request to a different value (e.g., from id=5 to id=10).
6. Forward the modified request.
7. Observe that the reservation belonging to another user has been altered or deleted.

Example Request (Intercepted):

POST /front/reservation.php HTTP/1.1
Host: vulnerable-glpi.local
Content-Type: application/x-www-form-urlencoded
Cookie: glpi_xxx=...

id=5&itemtype=Computer&items_id=12&begin=2025-01-01&end=2025-01-02&action=update

Modified Request:

POST /front/reservation.php HTTP/1.1
Host: vulnerable-glpi.local
Content-Type: application/x-www-form-urlencoded
Cookie: glpi_xxx=...

id=10&itemtype=Computer&items_id=12&begin=2025-01-01&end=2025-01-02&action=update

Blue Team (Detection & Defense)

Detection:

• Monitor for unusual patterns in reservation modification requests, especially rapid changes to different id values.
• Look for failed authorization attempts (e.g., 403 errors) that may indicate scanning for vulnerable endpoints.
• Use the detection rules provided in the next section.

Defense:

• Immediately upgrade to GLPI version 10.0.19 or later.
• Implement a Web Application Firewall (WAF) rule to block requests with suspicious id parameter manipulation.
• Enforce the principle of least privilege for user accounts.
• Conduct regular security audits and code reviews.

Indicators of Compromise (IOCs)

• Network IOCs:
  • HTTP requests to /front/reservation.php with multiple different id values from the same user session in a short period.
  • HTTP requests with id parameters that do not correspond to the user's own reservations.
• Log IOCs:
  • GLPI logs showing update or delete actions on reservations where the users_id does not match the session user.
  • Web server logs showing 403 errors on /front/reservation.php followed by successful 200 responses with different id values.
• File IOCs:
  • No specific file-based IOCs are expected, as this is a logic flaw.

Detection Engineering

YARA Rule

rule Detect_GLPI_Reservation_IDOR_Exploit {
    meta:
        description = "Detects potential exploitation of CVE-2025-53357 in GLPI logs"
        author = "Valters IT"
        date = "2025-01-01"
        reference = "CVE-2025-53357"
    strings:
        $s1 = "reservation" nocase
        $s2 = "update" nocase
        $s3 = "delete" nocase
        $s4 = "id="
    condition:
        all of ($s1, $s4) and any of ($s2, $s3)
}

Sigma Rule

title: GLPI Reservation IDOR Exploitation Attempt
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects attempts to exploit CVE-2025-53357 by modifying reservation IDs
author: Valters IT
date: 2025-01-01
logsource:
    category: webserver
    product: apache
detection:
    selection:
        cs-method: 'POST'
        cs-uri-stem: '/front/reservation.php'
        cs-uri-query|contains: 'id='
    condition: selection
falsepositives:
    - Legitimate reservation modifications by authorized users
level: medium

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"GLPI Reservation IDOR Exploit Attempt"; flow:to_server,established; content:"POST"; http_method; content:"/front/reservation.php"; http_uri; content:"id="; http_client_body; pcre:"/id=\d+/"; classtype:attempted-recon; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Upgrade GLPI: The primary remediation is to upgrade to GLPI version 10.0.19 or later. This is the only official patch.
2. Apply Virtual Patching: If immediate upgrade is not possible, implement a WAF rule to block requests to /front/reservation.php where the id parameter is manipulated in a suspicious manner.
3. Review User Permissions: Ensure that only necessary users have access to the reservation management module.

Long-Term Mitigations:

1. Code Review: Conduct a thorough code review of all modules that handle user-owned resources to identify similar IDOR vulnerabilities.
2. Implement Authorization Checks: Ensure that all actions on user-owned resources include server-side ownership verification.
3. Security Training: Train developers on secure coding practices, particularly regarding authorization and access control.

Valters IT Signature:

This report was generated by Valters IT Cyber Threat Intelligence.
For more information, visit https://valters-it.com