CVE-2026-63498: 
PHP 취약성 분석 및 완화

CVE-2026-63498 is a stored Cross-Site Scripting (XSS) vulnerability in Snipe-IT, an open-source IT asset and license management system, affecting all versions prior to 8.7.0. The flaw exists in the uploaded-files API endpoint (GET /api/v1/{object_type}/{id}/files/{file_id}), where the API controller fails to apply the safe-inline allowlist enforced by the equivalent web controller, allowing attacker-controlled XML/XSLT files to be rendered as active browser content. It was first published to the GitHub Advisory Database on September 24, 2026, and carries a CVSS v3.1 base score of 8.7 (High) (Github Advisory).

The root cause (CWE-79) is an inconsistency between the web and API controllers: app/Http/Controllers/Api/UploadedFilesController.php's show() method honors the ?inline=true query parameter and calls Storage::download() with Content-Disposition: inline without invoking StorageHelper::allowSafeInline(), which the non-API controller correctly calls. Because config/filesystems.php includes xml in the allowed upload extensions and PHP's finfo detects uploaded XSLT/XML files as text/xml (not image/svg+xml), they bypass SVG-specific sanitization and are stored unchanged. When a victim's browser opens the inline URL, Chromium processes the xml-stylesheet processing instruction, fetches the attacker-uploaded XSLT from the same origin, and executes the JavaScript produced by the transform — compounded by the default CSP containing script-src 'self' 'unsafe-inline' 'unsafe-eval', which does not block the injected script (Github Advisory, Snipe-IT Advisory).

Successful exploitation allows an attacker to execute arbitrary JavaScript in the Snipe-IT origin under the victim's authenticated session, enabling reading of same-origin pages and API responses, performing state-changing actions with the victim's privileges, and exfiltrating sensitive asset, user, license, and configuration data. If a superuser opens the malicious attachment, the attack can result in full administrative account compromise. While HttpOnly cookies cannot be read directly, the attacker can still issue authenticated same-origin API requests and read their responses on behalf of the victim (Github Advisory).

Exploitation requires an authenticated attacker with file-management permissions on at least one supported object type, plus one victim interaction (the victim must open the crafted attachment URL while authenticated). A detailed proof-of-concept is publicly documented in the GitHub Security Advisory, including specific curl commands and file payloads. As of the advisory publication date, there is no evidence of in-the-wild exploitation, no known threat actor attribution, and the EPSS score is 0.0. The vulnerability is not listed in the CISA KEV catalog (Github Advisory, Feedly).

1. Obtain credentials: Acquire an API token for a Snipe-IT account with file-management access to at least one supported object (e.g., an asset model).
2. Create the malicious XSLT stylesheet: Craft a file named style.xml containing an XSLT template that generates an HTML document with embedded JavaScript (e.g., document.getElementById('result').textContent = 'XSS_EXECUTED'; document.title = 'SNIPE_XSS';). PHP finfo will detect this as text/xml.
3. Upload the XSLT via the API: curl -i -H 'Authorization: Bearer ATTACKER_API_TOKEN' -H 'Accept: application/json' -F 'file[]=@style.xml;type=text/xml' 'https://snipe-it.example/api/v1/models/1/files'. Note the returned file ID (STYLE_FILE_ID).
4. Create the referencing XML document: Craft data.xml containing an <?xml-stylesheet type="text/xsl" href="/api/v1/models/1/files/STYLE_FILE_ID?inline=true"?> processing instruction pointing to the uploaded stylesheet.
5. Upload the XML document: Upload data.xml via the same API endpoint and note its file ID (DATA_FILE_ID).
6. Deliver the payload URL to the victim: Send the victim (who must be authenticated and authorized to view the object's files) the URL https://snipe-it.example/api/v1/models/1/files/DATA_FILE_ID?inline=true.
7. JavaScript executes in victim's context: When the victim opens the URL in their browser, Chromium fetches and applies the XSLT, executing the attacker's JavaScript in the Snipe-IT origin with the victim's session privileges, enabling data exfiltration or authenticated actions (Github Advisory, Snipe-IT Advisory).

• Network: Unusual GET requests to /api/v1/{object_type}/{id}/files/{file_id}?inline=true for XML/XSLT file IDs; same-origin API requests (e.g., to /api/v1/users, /api/v1/assets) originating from a browser session shortly after an inline file access, potentially indicating scripted data exfiltration.
• File System / Storage: Presence of uploaded files with .xml extension in the Snipe-IT private uploads directory (e.g., private_uploads/assets/ or private_uploads/models/) that contain XSLT markup or xml-stylesheet processing instructions.
• Logs: Web/API access logs showing POST requests to /api/v1/{object_type}/{id}/files uploading text/xml content, followed by GET requests to the same file with ?inline=true; action log entries (action_logs table) recording XML file uploads by a user who does not typically upload such files.
• Application Logs: Laravel logs showing file uploads of type text/xml that were not flagged by the SVG sanitizer, indicating they bypassed image-specific checks (Github Advisory).

Upgrade Snipe-IT to version 8.7.0 or later, which fixes the vulnerability by adding an allowSafeInline() check to the API controller's show() method and introducing a strict allowed_inline_display allowlist in config/filesystems.php that cross-validates both file extension and server-detected MIME type before permitting inline responses (Snipe-IT Release, Patch Commit). As an interim workaround until patching is possible, restrict file-management permissions to the minimum set of trusted users and educate users to avoid opening attachment URLs received from other users. Removing xml from the allowed_upload_extensions_array in config/filesystems.php would also prevent XML uploads entirely, though this may impact legitimate workflows (Github Advisory).

The vulnerability was reported responsibly by security researchers B1gN0Se and Rajib-Mahmud through GitHub's Security Advisory program, and remediated by the Snipe-IT maintainer (snipe). The v8.7.0 release notes acknowledge 44 security fixes in the release cycle and thank the responsible disclosure reporters by handle. No significant broader media coverage or notable public researcher commentary beyond the advisory itself has been identified at this time (Snipe-IT Release, Github Advisory).