CVE-2025-53113

Executive Summary

CVE-2025-53113 is a low-severity authorization bypass vulnerability in GLPI (Gestionnaire Libre de Parc Informatique), an open-source IT asset and service management software. The flaw affects versions 0.65 through 10.0.18 and allows a technician with valid credentials to use the "external links" feature to fetch information on items they do not have the right to view. This is a classic case of missing authorization checks (CWE-862) on a specific feature. The vulnerability has a CVSS score of 2.7, indicating minimal direct impact, but it can be used to leak sensitive information about assets or tickets that should be restricted. No public proof-of-concept (PoC) or exploit code has been released, and the EPSS score is 0.0%, suggesting very low exploitation activity. The patch is available in GLPI version 10.0.19.

Supply Chain & Package Security

GLPI is a PHP-based application distributed via GitHub and its official website. It is not typically distributed through package managers like NPM or PyPI. However, organizations using GLPI should ensure they are sourcing the software from the official repository and verifying checksums. The vulnerability does not directly affect the supply chain, but the lack of a public patch commit or advisory details increases the risk of delayed patching.

CVSS Breakdown & Threat Level

• CVSS Score: 2.7 (Low)
• Vector: CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N
• Attack Vector (AV): Network (N) – The vulnerability can be exploited remotely.
• Attack Complexity (AC): Low (L) – No special conditions are required.
• Privileges Required (PR): High (H) – The attacker must be an authenticated technician.
• User Interaction (UI): None (N) – No user interaction is needed.
• Scope (S): Unchanged (U) – The vulnerable component and the impacted component are the same.
• Confidentiality (C): Low (L) – Limited information disclosure.
• Integrity (I): None (N) – No data modification.
• Availability (A): None (N) – No impact on availability.

Threat Level: Low. The requirement for authenticated access and the limited information disclosure make this a low-priority vulnerability. However, in environments with strict data segregation (e.g., MSPs), it could be used to leak client-specific information.

Deep Dive & Mechanics

GLPI's "external links" feature allows technicians to define and use links to external resources (e.g., knowledge bases, monitoring tools) that are dynamically populated with item data. The vulnerability arises because the feature does not properly verify the user's permissions on the target item before fetching and displaying the external link content.

Technical Flow:

1. A technician with high privileges (e.g., super-admin) creates an external link definition that includes a URL template with placeholders (e.g., https://monitoring.example.com/asset/{id}).
2. A lower-privileged technician, who should not have access to certain assets, uses the external link feature on an item they can see (e.g., a ticket).
3. The external link feature processes the URL template and fetches data from the external resource, potentially including information about items the technician is not authorized to view.
4. The fetched data is displayed to the technician, bypassing the intended access controls.

The root cause is a missing authorization check in the code that handles external link execution. The patch in version 10.0.19 likely adds a permission verification step before processing the external link.

Vulnerable vs. Patched Code

Since no specific patch commit is available, the following is a hypothetical representation of the vulnerable and patched code.

Vulnerable Code (GLPI < 10.0.19):

// In some ExternalLink class or controller
public function executeLink($itemtype, $items_id) {
    // No permission check on the target item
    $link = $this->fields['url'];
    $link = str_replace('{id}', $items_id, $link);
    // Fetch and return the external content
    return file_get_contents($link);
}

Patched Code (GLPI >= 10.0.19):

// In some ExternalLink class or controller
public function executeLink($itemtype, $items_id) {
    // Check if the current user has read rights on the target item
    if (!Session::haveRight($itemtype, READ)) {
        throw new \RuntimeException("Access denied");
    }
    $link = $this->fields['url'];
    $link = str_replace('{id}', $items_id, $link);
    // Fetch and return the external content
    return file_get_contents($link);
}

Exploitation & Lab Setup

Red Team

Prerequisites:

• A GLPI instance running version 0.65 to 10.0.18.
• Valid credentials for a technician account (e.g., tech1).
• An external link definition that points to a resource containing sensitive data (e.g., a monitoring dashboard with asset details).

Steps:

1. Log in as a technician with limited rights (e.g., only ticket access).
2. Navigate to an item you have access to (e.g., a ticket).
3. Use the external link feature (e.g., click on a link labeled "View Asset Details").
4. Observe that the external link fetches and displays information about an asset you should not have access to.

Example URL Manipulation: If the external link template is https://monitoring.example.com/asset/{id}, and you have access to ticket ID 100, but the asset ID is 200, the link might still fetch data for asset 200 if the ticket is associated with it.

Blue Team

Detection:

• Monitor GLPI access logs for unusual patterns of external link usage.
• Look for technicians accessing external links that reference items outside their permission scope.
• Use the Sigma rule provided in the Detection Engineering section.

Hunting:

• Query the GLPI database for external link definitions that use placeholders like {id} or {itemtype}.
• Review audit logs for failed permission checks (if logging is enabled).

Mitigation:

• Immediately upgrade to GLPI version 10.0.19.
• If upgrade is not possible, disable the external links feature for non-admin users via the GLPI configuration.
• Implement network segmentation to limit the reach of external links.

Indicators of Compromise (IOCs)

• Log Entries: GLPI logs showing successful external link fetches for items where the user's permission level is insufficient.
• Database Queries: Unusual queries to the glpi_externallinks table.
• Network Traffic: Outbound HTTP requests from the GLPI server to external URLs that contain item IDs in the path or query string.

Detection Engineering

YARA Rule

rule Detect_GLPI_External_Link_Abuse {
    meta:
        description = "Detects potential abuse of GLPI external links feature (CVE-2025-53113)"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-53113"
    strings:
        $php_function = "file_get_contents" nocase
        $url_pattern = /https?:\/\/[^\s]*\{id\}[^\s]*/ nocase
        $class_name = "ExternalLink" nocase
    condition:
        $php_function and $url_pattern and $class_name
}

Sigma Rule

title: GLPI External Link Authorization Bypass
id: 7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d
status: experimental
description: Detects potential exploitation of CVE-2025-53113 in GLPI
author: Valters IT
date: 2025-04-10
logsource:
    category: application
    product: glpi
detection:
    selection:
        event_type: "external_link_execution"
        user_role: "technician"
        target_item_permission: "none"
    condition: selection
falsepositives:
    - Legitimate use of external links by authorized users
level: low

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (
    msg:"GLPI External Link Authorization Bypass (CVE-2025-53113)";
    flow:to_server,established;
    content:"/glpi/"; http_uri;
    content:"externalLink"; http_uri;
    pcre:"/\{id\}/Ui";
    classtype:attempted-recon;
    sid:1000001;
    rev:1;
)

Remediation & Mitigation

Immediate Actions:

1. Upgrade GLPI to version 10.0.19 or later. This is the only official fix.
2. Disable external links for non-admin users via the GLPI configuration interface (Setup > External links).
3. Review external link definitions and remove any that could leak sensitive data.

Long-term Measures:

• Implement a strict access control policy for all GLPI features.
• Regularly audit user permissions and external link usage.
• Monitor GLPI security advisories and apply patches promptly.

Workarounds (if upgrade is not possible):

• Use a web application firewall (WAF) to block requests containing {id} in the URL path.
• Restrict outbound HTTP access from the GLPI server to only trusted external resources.

Valters IT