GHSA-p9h3-gvpq-5539: XSS
Impact A user with the "customfields.create" permission can store HTML/JS in a Custom Field name, which is later rendered as an asset-list column title WITHOUT escaping at app/Presenters/AssetPresenter.php line 364 ('title' => $field->name) and injected into the table header by the bundled bootstrap-table plugin. It executes for anyone who opens an asset list (e.g. /hardware), including superusers, on page load with no interaction. Since "customfields.create" can be granted to non-superusers, a lower-privileged user gets script execution in a superuser's session -> privilege escalation.
STEPS TO REPRODUCE 1. As a user with "customfields.create", create a Custom Field named: <img src=x onerror=alert(1)> 2. Add the field to a fieldset that is associated with an asset model. 3. Open /hardware -> the payload executes on load.
DEMONSTRATED IMPACT An account holding ONLY "customfields.create" (HTTP 403 on /users) planted a payload that, when a superuser opened /hardware, issued an authenticated request in that session and granted the attacker's own account the "superuser" permission (afterwards: GET /users = 200, isSuperUser() = true).
ROOT CAUSE - Blade {{ }} encodes the data-columns attribute, but the browser decodes it back before bootstrap-table reads the title; bootstrap-table then renders the header title unescaped because its table-level "escape" option defaults to false and is never enabled. (The per-column 'escape' => true covers cell values, not the header title.) Patches Patched in https://github.com/grokability/snipe-it/commit/58754e4e3b86b58a0c4523012ef04a2ae990d2c8
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
composer/snipe/snipe-itto a version that resolves this vulnerability.Fixed in 8.7.0 - Upgrade
Upgrade
snipe-itto a version that resolves this vulnerability.Patch 58754e4e3b86b58a0c4523012ef04a2ae990d2c8
Event History
Frequently Asked Questions
Who can exploit this issue, and who is at risk when the payload runs?
Any account granted the customfields.create permission can plant the malicious custom-field name, even if it is not a superuser. The payload executes in the session of any user who opens an affected asset list, including superusers.
What conditions are required for exploitation?
The attacker must be able to create a custom field and add it to a fieldset associated with an asset model. A target then needs only to open an asset list such as /hardware; no further interaction is required.
Can this lead to privilege escalation?
Yes. The demonstrated impact shows a user with only customfields.create using script execution in a superuser's session to grant the attacker superuser permission.
How can I check whether my instance may already be affected?
Review custom-field names for HTML or JavaScript payloads, particularly fields included in fieldsets associated with asset models. Also investigate unexpected permission changes or accounts that have gained superuser access.
What can be done while patching is pending?
Restrict customfields.create to trusted administrators and review or remove suspicious custom fields from asset-related fieldsets. Limiting access to affected asset-list pages can reduce exposure to stored payloads until remediation is deployed.