CVE-2026-62368 is a high severity (CVSS 8.1) stored cross-site scripting flaw in Snipe-IT, the IT asset management system. A user who can create custom fields can plant markup that runs in another user's session when they open an asset list. Version 8.7.0 fixes it.
What's affected
The record says Snipe-IT before 8.7.0 is affected. The GitHub advisory (GHSA-p9h3-gvpq-5539) lists the composer package snipe/snipe-it, affected versions up to and including 8.6.3, patched in 8.7.0, and rates it High with a score of 8.1. The record agrees on the score and severity.
The weakness is CWE-79. A custom field name is shown as a column title in the asset list without escaping. Any user who holds the customfields.create permission can set that name, and the stored value then runs for whoever opens an asset list for the linked fieldset, with no further click needed. Because the permission can be given to people who are not superusers, the advisory treats it as a privilege escalation path: script running in a superuser's session acts with the superuser's rights.
The vector shows high privileges required, user interaction required and a changed scope.
How to check if you're exposed
Start with the version your instance reports in its admin area and compare it with 8.7.0.
For container deployments, look at the image tag.
docker ps --format '{{.Names}} {{.Image}}' | grep -i snipe
Then review who can create custom fields. In the admin user and group permission screens, list the accounts that hold customfields.create. Anyone on that list who is not a trusted administrator is worth a conversation.
Finally, look through your existing custom field names for anything that looks like markup rather than a plain label. Field names should read like ordinary words.
Whatever the product, a current inventory of what you run is what turns a CVE notice into a quick answer. The Gold page for this CVE tracks how its record changes over time, and the free in-browser dependency scan at gold.safeguard.sh/scan covers the application libraries you ship.
What to do now
- Upgrade Snipe-IT to 8.7.0 or later. The advisory names commit 58754e4 as the fix.
- Remove customfields.create from any account or group that does not need it.
- Review current custom field names and fieldsets and clean up anything that contains markup.
- If you suspect a bad field name was viewed by an administrator, review recent permission changes and audit log entries for unexpected grants.
- Add a Content Security Policy at your reverse proxy if you do not have one. It will not replace the patch, but it limits what injected script can do.
Why it matters
Stored XSS is dangerous mainly because of who sees it. The attacker does not need to reach the victim; the application delivers the script. In an asset system the viewers are often administrators, so a minor permission becomes a route to a major one.
The root cause in the advisory is a rendering detail. The template encodes the value, the browser decodes it back, and the table plugin then writes the header title without escaping because its escape option is off. The fix pattern is general: escape at the point of output, and know which layer actually writes to the page. The record does not list the CVE as exploited in the wild, and it is not in the CISA KEV catalog.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Is a low privileged account enough to exploit this?
No. The permission needed is customfields.create, and the vector requires high privileges. The risk is that this permission is sometimes granted to people who are not full administrators.
Sources
Last reviewed: 18 October 2026.
