CVE-2026-63498: Stored Cross-Site Scripting via Inline XML Rendering in Snipe-IT API

Snipe-IT is an open-source IT asset and license management platform built on the Laravel framework. The application implements standard upload functionalities for administrative tracking of invoices, licenses, and hardware assets. These file uploads are exposed via both a standard web interface and a comprehensive REST API engine.

The REST API exposes file retrieval capability through the app/Http/Controllers/Api/UploadedFilesController.php controller. This component serves as an intermediary proxy, pulling private objects from system storage and serving them back to authenticated clients. The vulnerability exists because the API endpoint does not validate file types before setting inline rendering instructions.

This design flaw maps directly to CWE-79 (Improper Neutralization of Input During Web Page Generation). By requesting stored files with the inline query parameter, attackers bypass the strict file-type and extension sanitization controls present in the standard web front-end. The security boundary between raw user-supplied data and browser execution is thus broken.

The root cause lies in the application's logical implementation of the file-retrieval routine in the show() method of the API controller. Unlike the traditional web interface, which employs strict extension allowlists before deciding to send an inline response, the API controller unconditionally set the Content-Disposition header to inline if the parameter inline=true was specified.

When an application serves XML content with Content-Disposition: inline, the web browser parses the file as active content rather than downloading it. This parsing behavior includes processing document prologue instructions, such as XML stylesheet associations. If an attacker links an XML document to an XSLT template, the browser will retrieve and execute the transformation sheets automatically.

This processing framework allows the inclusion of scripting blocks within the XSLT stylesheet. Because the file is served from the same domain as the Snipe-IT application, the browser executes the compiled scripts directly inside the application's origin context. Consequently, the script gains complete programmatic access to the Document Object Model (DOM), local storage, and session cookies.

Let us examine the vulnerable block in app/Http/Controllers/Api/UploadedFilesController.php before the patch. The controller immediately executed Storage::download and attached an unvalidated Content-Disposition header. There was no inspection of the physical file's extension or its MIME-type properties prior to triggering the inline response pipeline.

The logic in the vulnerable version of the controller was structured as follows:

if (request('inline') == 'true') {
    $headers = [
        'Content-Disposition' => 'inline',
    ];
    return Storage::download(self::$map_storage_path[$object_type].$log->filename, $log->filename, $headers);
}

The patched implementation introduces strict validation using a newly added helper utility, StorageHelper::allowSafeInline. This function verifies that the file extension is registered within an allowed subset in the system configuration file config/filesystems.php. It further ensures that the actual MIME type matches the file extension, protecting against extension-spoofing techniques:

if (request('inline') == 'true') {
    $path = self::$map_storage_path[$object_type];
    // Only allowlisted extensions may be served inline
    if (! StorageHelper::allowSafeInline($path.$log->filename)) {
        return StorageHelper::downloader($path.$log->filename);
    }
    return Storage::download($path.$log->filename, $log->filename, [
        'Content-Disposition' => 'inline',
        'X-Content-Type-Options' => 'nosniff',
    ]);
}

Additionally, the patch updates the default downloader() helper to force secure response headers on files that are not permitted inline. By appending Content-Type: application/octet-stream and X-Content-Type-Options: nosniff, the application prevents the browser from sniffing the payload and executing embedded scripts, ensuring complete protection even if the user manually attempts to trigger execution.

Exploitation requires an authenticated session with basic privileges to upload file attachments to inventory objects, such as assets or models. The attacker first crafts a malicious XML payload referencing an external or locally hosted XSLT file. The XSLT schema contains embedded JavaScript elements designed to execute administrative actions silently.

The attack proceeds in a multi-step sequence. The attacker uploads both files to the system, receiving unique identifiers for each object. The XML payload is explicitly structured to point its stylesheet reference path to the API retrieval URL of the uploaded XSLT payload, leveraging the inline flag to force processing.

A visual representation of the exploitation process details the exact network and browser interaction paths:

When an authorized manager accesses the inline XML attachment, the browser processes the stylesheet translation. The stylesheet payload then runs arbitrary scripts to read CSRF tokens, access Laravel API endpoints, and initiate unauthorized actions on behalf of the administrator.

This vulnerability poses a high risk to administrative confidentiality and integrity. Because Snipe-IT utilizes authorization tokens and session identifiers within the local browser storage, executing code in the victim's origin context completely bypasses standard access control mechanisms.

The attacker can gain full control over the asset management database by executing API queries through the compromised browser context. Actions include creating new high-privilege administrators, deleting hardware tracking databases, or exfiltrating sensitive credential sheets.

The impact is elevated because the vulnerability requires very low privileges to exploit, needing only standard attachment upload permissions. The CVSS score of 8.7 reflects this high potential for lateral escalation and the ease of network-based delivery.

The primary remediation strategy is upgrading the Snipe-IT deployment to version 8.7.0 or higher. This update restricts inline rendering to verified safe file extensions and enforces MIME-type checking, ensuring that active content like XML and HTML cannot execute via the API.

In environments where patching must be deferred, temporary network and server-level mitigations should be applied. Administrators can use a web application firewall to block requests matching the pattern /api/v1/*/files/*?inline=true if the underlying file is an XML or HTML document.

Additionally, configuring the reverse proxy to send protective headers acts as a robust defense-in-depth measure. Forcing Content-Security-Policy: sandbox for the uploads path restricts all script execution, ensuring that browsers render attachments securely without risk to the primary application session.