CVE-2026-63498: Snipe-IT XSS Vulnerability

CVE-2026-63498 Overview

CVE-2026-63498 is a stored Cross-Site Scripting (XSS) vulnerability [CWE-79] in Snipe-IT, an open-source IT asset and license management system developed by Grokability. The flaw affects the API endpoint GET /api/v1/{object_type}/{id}/files/{file_id} in versions prior to 8.7.0. An authenticated user with file-management access can upload XML or XSLT attachments and retrieve them with the inline=true parameter. The API controller omits the safe-inline allowlist enforced by the equivalent web controller, letting the browser process an attacker-controlled xml-stylesheet reference and execute JavaScript in the Snipe-IT origin.

Critical Impact
A victim who opens the attachment URL triggers script execution with their session, enabling same-origin data reads and authenticated actions as the victim.

Affected Products

Snipe-IT versions prior to 8.7.0
Grokability Snipe-IT asset management platform
Deployments exposing the /api/v1/{object_type}/{id}/files/{file_id} endpoint

Discovery Timeline

2026-09-24 - CVE-2026-63498 published to NVD
2026-09-29 - Last updated in NVD database

Technical Details for CVE-2026-63498

Vulnerability Analysis

The vulnerability lives in the show() method of app/Http/Controllers/Api/UploadedFilesController.php. When a client requests an uploaded file with inline=true, the controller returns the file with a Content-Disposition: inline header without validating the file type against a safe-inline allowlist. The equivalent web controller already enforces that allowlist, so the API path diverges from the hardened behavior.

Browsers will parse an inline XML response and honor an xml-stylesheet processing instruction pointing to attacker-controlled XSLT. The XSLT engine can emit <script> elements that execute in the Snipe-IT origin. Because requests to the endpoint carry the victim's session cookie, the injected script can read same-origin data and invoke any API action the victim is authorized to perform.

Root Cause

The root cause is missing MIME-type and extension validation on an inline response path. The API controller trusts the uploaded file type and lets the browser determine how to render it. MIME sniffing is not disabled, and X-Content-Type-Options: nosniff is absent from the response. Uploads with .xml or .xslt extensions therefore reach the browser as active content.

Attack Vector

Exploitation requires an authenticated attacker with file-upload privileges and a victim authorized to view the target object. The attacker uploads a crafted XML file referencing a hosted XSLT stylesheet. The attacker then shares the inline URL with the victim or embeds it where the victim will fetch it. When the victim's browser loads the response, the stylesheet executes JavaScript in the Snipe-IT origin and performs actions under the victim's identity.

php

// Patch to app/Http/Controllers/Api/UploadedFilesController.php
if (request('inline') == 'true') {
    $path = self::$map_storage_path[$object_type];

    // Only allowlisted extensions may be served inline. Everything
    // else (including XML, which can pull an XSLT stylesheet and
    // execute script in-origin) falls through to a download response.
    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',
    ]);
}

Source: GitHub Commit e929b31

Detection Methods for CVE-2026-63498

Indicators of Compromise

Uploaded files with .xml, .xsl, or .xslt extensions attached to Snipe-IT assets, licenses, or accessories.
HTTP requests to /api/v1/{object_type}/{id}/files/{file_id}?inline=true returning XML content types.
Outbound requests from client browsers to third-party domains referenced in xml-stylesheet processing instructions.

Detection Strategies

Inspect uploaded attachments in the Snipe-IT storage path for XML files containing <?xml-stylesheet processing instructions.
Review web server access logs for inline=true query parameters on the uploaded-files API endpoint.
Correlate authenticated API actions with recent file-view events from the same session to identify suspicious automation.

Monitoring Recommendations

Alert on new file uploads with XML or XSLT MIME types or extensions, particularly from non-administrator accounts.
Monitor browser-origin API calls that follow file-view events, since these may indicate script-driven actions.
Enable audit logging on file-management endpoints and ship logs to a central SIEM for correlation.

How to Mitigate CVE-2026-63498

Immediate Actions Required

Upgrade Snipe-IT to version 8.7.0 or later, which contains the official fix.
Audit existing uploaded attachments for .xml, .xsl, and .xslt files and remove any not required for business operations.
Review user roles and restrict file-management privileges to accounts that genuinely require them.

Patch Information

The fix is delivered in Snipe-IT v8.7.0 and committed in e929b31. The patch adds a StorageHelper::allowSafeInline() allowlist check in the API controller and hardens StorageHelper::downloader() to force Content-Type: application/octet-stream and X-Content-Type-Options: nosniff on download responses. Full details are available in the GitHub Security Advisory GHSA-396x-xmvh-p563.

Workarounds

If patching is not immediate, block or filter requests containing inline=true to /api/v1/*/files/* at a reverse proxy or web application firewall.
Enforce Content-Security-Policy headers restricting script execution to the Snipe-IT origin without unsafe-inline.
Add a web server rule to append X-Content-Type-Options: nosniff to all responses from the uploaded-files endpoint.

bash

# Example nginx rule to strip inline rendering on the uploaded-files API
location ~ ^/api/v1/[^/]+/[^/]+/files/[^/]+$ {
    if ($arg_inline = "true") {
        return 403;
    }
    add_header X-Content-Type-Options "nosniff" always;
    proxy_pass http://snipeit_backend;
}