An authenticated user with permission to upload files can upload a malicious XSLT stylesheet and an XML document that references it via the xml-stylesheet instruction. When a victim views the XML file through the API with the inline=true parameter, the browser parses the XSLT and executes the embedded JavaScript within the context of the Snipe-IT origin. This allows the attacker to perform unauthorized actions on behalf of the victim, access sensitive information, or escalate privileges if a superuser is targeted. The vulnerability was reproduced in versions prior to 8.7.0.

Attack Chain

1. Attacker authenticates to the Snipe-IT instance with a user account permitted to upload files to at least one object.
2. Attacker prepares a malicious XSLT file containing an embedded payload (e.g., <script>...</script>).
3. Attacker uses the API POST /api/v1/{object_type}/{id}/files to upload the XSLT stylesheet; the system stores the file as text/xml.
4. Attacker records the assigned ID of the stored XSLT file.
5. Attacker creates an XML document containing an <?xml-stylesheet ...?> processing instruction pointing to the URL of the previously uploaded XSLT file.
6. Attacker uploads the referencing XML document via the same API endpoint and records its ID.
7. Attacker lures an authenticated victim to visit the URL .../files/{DATA_FILE_ID}?inline=true within the Snipe-IT application.
8. Victim's browser loads the XML, interprets the stylesheet instruction, and executes the embedded JavaScript in the Snipe-IT session context.

Impact

Successful exploitation allows for complete compromise of the victim's session within the Snipe-IT application. Consequences include the ability to read same-origin data (asset, user, and license information), perform authenticated state-changing actions, and potentially achieve full administrative account compromise if a superuser interacts with the malicious file.

Recommendation

1. Upgrade Snipe-IT to version 8.7.0 or later to ensure the API controller correctly implements StorageHelper::allowSafeInline() for file downloads.
2. Review recent access logs for the /api/v1/*/files/* endpoints to identify unusual file upload patterns, particularly involving XML content.
3. Limit file upload permissions to the minimum number of users required for business operations to reduce the attack surface.