CVE-2025-53111

Executive Summary

CVE-2025-53111 is a missing authorization vulnerability in GLPI, a popular open-source IT asset and service management software. The flaw affects all versions from 0.80 through 10.0.18, allowing an unauthenticated or low-privileged attacker to access resources that should be restricted. The vulnerability stems from a lack of permission checks in certain API endpoints or web routes, enabling unauthorized read or limited write access to sensitive data. With a CVSS score of 6.5 (Medium), the risk is elevated due to the network-based, low-complexity attack vector that requires no authentication. The vendor has released a fix in version 10.0.19, but no public exploit code or proof-of-concept is currently available. This report provides a comprehensive technical analysis, detection guidance, and remediation steps.

CVSS Breakdown & Threat Level

• CVSS Score: 6.5 (Medium)
• Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
• Attack Vector (AV): Network – The vulnerability can be exploited remotely over the network.
• Attack Complexity (AC): Low – No special conditions or complex attack sequences are required.
• Privileges Required (PR): None – The attacker does not need any authentication.
• User Interaction (UI): None – No user action is required for exploitation.
• Scope (S): Unchanged – The exploit cannot affect resources beyond the vulnerable component.
• Confidentiality (C): Low – Limited disclosure of information is possible.
• Integrity (I): Low – Limited modification of data is possible.
• Availability (A): None – No impact on system availability.

Threat Level: Medium. The vulnerability is easy to exploit remotely without authentication, but the impact is limited to low confidentiality and integrity loss. However, in the context of an IT management system, even low-level access can lead to significant information disclosure or privilege escalation chains.

Deep Dive & Mechanics

The vulnerability resides in GLPI's permission validation logic. GLPI uses a role-based access control (RBAC) system to restrict access to various modules (e.g., tickets, assets, users). In affected versions, certain API endpoints or web routes fail to enforce these checks, allowing an attacker to access resources without proper authorization.

Root Cause: The checkRight() or similar authorization function is either missing or incorrectly implemented in specific controllers or views. This allows direct access to data retrieval or modification functions without verifying the user's session or permissions.

Attack Vector: An attacker can craft HTTP requests to vulnerable endpoints, such as /apirest.php/... or /front/..., bypassing authentication checks. For example, a request to list all tickets or user accounts might succeed without a valid API token or session cookie.

Impact: An attacker could:

• Read sensitive data (e.g., ticket details, user lists, configuration settings).
• Modify low-impact data (e.g., update ticket status, change non-critical settings).
• Use the information for further attacks, such as social engineering or privilege escalation.

Affected Components: The vulnerability likely affects REST API endpoints and some front-end modules that handle resource listing or editing without proper permission checks.

Vulnerable vs. Patched Code

The fix in version 10.0.19 adds missing permission checks. Below is a conceptual comparison.

Vulnerable Code (e.g., in src/SomeController.php):

public function listTickets() {
    // No permission check
    $tickets = $this->ticketRepository->findAll();
    return $this->json($tickets);
}

Patched Code (version 10.0.19):

public function listTickets() {
    // Added permission check
    if (!$this->checkRight('ticket', READ)) {
        throw new AccessDeniedException();
    }
    $tickets = $this->ticketRepository->findAll();
    return $this->json($tickets);
}

The patch ensures that the checkRight() function is called before any data access, verifying the user has the required permission (e.g., READ for tickets). Similar checks are added to all vulnerable endpoints.

Exploitation & Lab Setup

Red Team (Offensive)

Prerequisites:

• A target running GLPI version 0.80 to 10.0.18.
• Network access to the GLPI web interface or API.

Exploitation Steps:

1. Identify Vulnerable Endpoints: Use a web scanner or manual testing to find endpoints that return data without authentication. Common targets include:

   • /apirest.php/Ticket/ (list tickets)
   • /apirest.php/User/ (list users)
   • /front/ticket.form.php (view ticket details)

2. Craft Unauthenticated Request: Use curl to access a resource without any session token.

   curl -X GET "http://target.com/apirest.php/Ticket/" -H "Content-Type: application/json"
   

3. Verify Unauthorized Access: If the response contains ticket data (e.g., JSON array of tickets), the endpoint is vulnerable.

4. Exploit for Data Exfiltration: Automate the extraction of sensitive data using a script.

   import requests
   target = "http://target.com/apirest.php/"
   endpoints = ["Ticket/", "User/", "Computer/"]
   for ep in endpoints:
       r = requests.get(target + ep)
       if r.status_code == 200:
           print(f"Data from {ep}: {r.text[:200]}")
   

Note: No public exploit code is available, so this is a generic approach.

Blue Team (Defensive)

Detection:

• Monitor for unusual HTTP requests to API endpoints without authentication headers.
• Look for spikes in 200 OK responses to endpoints that should require authentication.
• Use the detection rules provided in the Detection Engineering section.

Hunting:

• Search logs for requests to /apirest.php/ or /front/ from IPs not associated with authenticated sessions.
• Correlate with failed login attempts to identify potential scanning.

Containment:

• Immediately apply the patch by upgrading to version 10.0.19.
• If patching is delayed, implement a Web Application Firewall (WAF) rule to block unauthenticated access to sensitive endpoints.
• Restrict network access to the GLPI instance using firewall rules.

Indicators of Compromise (IOCs)

• Network IOCs:

  • HTTP requests to /apirest.php/ without Authorization or Session-Token headers.
  • Repeated GET requests to /front/ticket.form.php or similar from a single IP.
  • Unusual data volumes in API responses (e.g., large JSON payloads).

• File IOCs:

  • Access logs showing 200 OK responses to restricted endpoints without prior authentication.
  • Error logs with missing permission check warnings (if debug mode enabled).

• Behavioral IOCs:

  • Anomalous user activity, such as a user accessing tickets they should not see.
  • Multiple failed login attempts followed by successful data access (indicating brute-force + exploitation).

Detection Engineering

YARA Rule

rule CVE_2025_53111_GLPI_Unauthorized_Access {
    meta:
        description = "Detects attempts to exploit CVE-2025-53111 in GLPI by checking for unauthenticated API access"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-53111"
        severity = "medium"
    strings:
        $api_endpoint = "/apirest.php/"
        $ticket_path = "/Ticket/"
        $user_path = "/User/"
        $no_auth = "Authorization" nocase
    condition:
        any of ($api_endpoint, $ticket_path, $user_path) and not $no_auth
}

Sigma Rule

title: CVE-2025-53111 - GLPI Unauthorized API Access
id: 8a9b3c4d-5e6f-7a8b-9c0d-1e2f3a4b5c6d
status: experimental
description: Detects HTTP requests to GLPI API endpoints without authentication headers, indicating potential exploitation of CVE-2025-53111.
author: Valters IT
date: 2025-04-10
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2025-53111
logsource:
    category: webserver
    product: apache
    service: access_combined
detection:
    selection:
        cs-method: 'GET'
        cs-uri-stem|startswith:
            - '/apirest.php/Ticket/'
            - '/apirest.php/User/'
            - '/apirest.php/Computer/'
        sc-status: 200
    filter:
        cs-headers|contains: 'Authorization'
    condition: selection and not filter
falsepositives:
    - Legitimate unauthenticated endpoints (if any)
level: medium

Suricata Rule

alert http any any -> $HOME_NET any (
    msg:"CVE-2025-53111 - GLPI Unauthorized API Access Attempt";
    flow:to_server,established;
    content:"GET";
    http_method;
    content:"/apirest.php/";
    http_uri;
    pcre:"/\/apirest\.php\/(Ticket|User|Computer)\//";
    sid:10000001;
    rev:1;
    reference:cve,2025-53111;
    classtype:attempted-recon;
    priority:2;
)

Remediation & Mitigation

Immediate Actions:

1. Upgrade GLPI: Update to version 10.0.19 or later. This is the only complete fix.

   # For Debian/Ubuntu
   sudo apt update && sudo apt install glpi=10.0.19
   # For manual installations, download from https://github.com/glpi-project/glpi/releases
   

2. Apply WAF Rules: If immediate patching is not possible, deploy a WAF rule to block unauthenticated requests to sensitive API endpoints.

   # Example Nginx rule
   location ~ ^/apirest\.php/(Ticket|User|Computer)/ {
       if ($http_authorization = "") {
           return 403;
       }
   }
   

3. Restrict Network Access: Limit access to the GLPI web interface to trusted IPs only using firewall rules.

Long-Term Measures:

• Implement regular vulnerability scanning and patch management.
• Enable detailed logging and monitoring for all API access.
• Conduct periodic security audits of custom code and configurations.

Valters IT
Securing your digital assets with precision and expertise.