CVE-2026-55466 Overview
Snipe-IT, an open-source IT asset and license management system, contains a stored cross-site scripting (XSS) vulnerability [CWE-79] in versions prior to 8.6.2. The flaw resides in UploadFileRequest, which sanitizes SVG content only when PHP finfo reports the MIME type as image/svg+xml. The UploadedFilesController then serves attachments inline without invoking StorageHelper::allowSafeInline(). A low-privilege authenticated user can upload active XHTML or XML content that is later served same-origin and executes JavaScript in another user's browser. The issue is fixed in version 8.6.2.
Critical Impact
Authenticated attackers can execute arbitrary JavaScript in the browsers of other Snipe-IT users, enabling session theft, privilege abuse, and administrative account takeover.
Affected Products
- Snipe-IT versions prior to 8.6.2
- snipeitapp/snipe-it self-hosted deployments
- Snipe-IT instances allowing attachment uploads by low-privilege users
Discovery Timeline
- 2026-07-10 - CVE-2026-55466 published to NVD
- 2026-07-14 - Last updated in NVD database
Technical Details for CVE-2026-55466
Vulnerability Analysis
The vulnerability is a stored cross-site scripting flaw rooted in inconsistent MIME-type handling during file upload and serving. Snipe-IT's UploadFileRequest class relies on PHP's finfo extension to detect SVG files and apply sanitization. When finfo classifies uploaded content with a MIME type other than image/svg+xml, sanitization is skipped entirely. Attackers can craft XHTML or XML documents that browsers still parse and render as active content when served with a permissive Content-Type.
The UploadedFilesController compounds the issue by returning attachments with a Content-Disposition: inline header. Because attachments are served from the same origin as the application, injected JavaScript executes with full access to session cookies and the Snipe-IT DOM. Any authenticated user with permission to upload files can weaponize this behavior.
Root Cause
The root cause is twofold: input sanitization is gated on a narrow finfo MIME check that misses executable XML variants, and the file-serving path lacks a safe-inline gate. The absence of StorageHelper::allowSafeInline() on the download path means any file type is served inline on request.
Attack Vector
An authenticated attacker with upload permissions submits a malicious XHTML or XML file as an asset attachment. When another user, typically an administrator, opens the attachment inline through the Snipe-IT interface, the browser renders the file same-origin and executes the embedded script payload.
}
if (request('inline') == 'true') {
- $headers = [
- 'Content-Disposition' => 'inline',
- ];
+ $path = self::$map_storage_path[$object_type];
- return Storage::download(self::$map_storage_path[$object_type].$log->filename, $log->filename, $headers);
+ if (! StorageHelper::allowSafeInline($path.$log->filename)) {
+ return StorageHelper::downloader($path.$log->filename);
+ }
+
+ return Storage::download($path.$log->filename, $log->filename, ['Content-Disposition' => 'inline']);
}
return StorageHelper::downloader(self::$map_storage_path[$object_type].$log->filename);
Source: GitHub Commit 000cea0. The patch introduces an allowSafeInline() gate. When the file is not on the safe-inline allowlist, the controller falls back to StorageHelper::downloader(), forcing a download rather than inline rendering.
Detection Methods for CVE-2026-55466
Indicators of Compromise
- Attachment uploads with extensions or content of .xhtml, .xml, or malformed .svg files created by low-privilege user accounts.
- Web server logs showing GET requests to Snipe-IT attachment endpoints with the inline=true query parameter for non-image files.
- Outbound network requests from administrator browsers to attacker-controlled hosts shortly after opening a Snipe-IT attachment.
Detection Strategies
- Inspect stored files in Snipe-IT upload directories for <script>, onerror=, or xmlns="http://www.w3.org/1999/xhtml" markers within non-image attachments.
- Correlate file upload audit events with subsequent inline attachment views by privileged users to identify potential victim interactions.
- Enable Content Security Policy (CSP) reporting on the Snipe-IT origin and alert on inline script violations originating from attachment paths.
Monitoring Recommendations
- Log and review the Content-Type and Content-Disposition headers returned by the UploadedFilesController for anomalies.
- Monitor Snipe-IT authentication logs for administrator session anomalies immediately following attachment access events.
- Track file upload volume and file-type distribution per user to detect abusive uploads of XML or XHTML content.
How to Mitigate CVE-2026-55466
Immediate Actions Required
- Upgrade Snipe-IT to version 8.6.2 or later, which introduces the StorageHelper::allowSafeInline() gate on inline downloads.
- Audit existing attachments for uploaded XHTML, XML, or SVG files containing scriptable content and remove any malicious artifacts.
- Restrict file upload privileges to trusted user roles until patching is complete.
Patch Information
The fix is available in Snipe-IT v8.6.2. Details are published in GitHub Security Advisory GHSA-jhph-5q74-pmfx and applied via commit 000cea0. The release notes are documented in the GitHub Release v8.6.2.
Workarounds
- Configure the reverse proxy or web server to force Content-Disposition: attachment on all Snipe-IT attachment responses.
- Deploy a strict Content Security Policy that disallows inline scripts on the Snipe-IT origin to reduce XSS impact.
- Serve user-uploaded content from a distinct, sandboxed origin to prevent same-origin script execution against the application.
# Nginx workaround: force attachment download for Snipe-IT uploads
location ~ ^/uploads/ {
add_header Content-Disposition "attachment" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Content-Security-Policy "default-src 'none'; sandbox" always;
}
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
