Summary
Snipe-IT contains a stored cross-site scripting vulnerability in asset-list header titles derived from CustomField.name values. A user able to create custom fields can store markup that executes when another user opens an associated asset list, potentially exposing same-origin data or performing actions with the victim's privileges.
Affected context
The issue occurs in Snipe-IT deployments where users with the customfields.create permission can define custom field names and those names are rendered as bootstrap-table header titles in asset-list pages. Risk is present when the value is output without context-appropriate HTML escaping and another user, particularly a privileged user, views an affected list.
Exploit preconditions
- Attack surface: Snipe-IT web asset-list pages
- Required access: Permission to create custom fields, specifically customfields.create
- Trigger point: A victim opens an asset-list page associated with the affected fieldset
- Why exploitation is possible: Attacker-controlled CustomField.name data is stored and later inserted into a header title without adequate output encoding
- Victim context: The victim must access the affected page while authenticated
Why this happens
The vulnerability results from storing attacker-controlled markup and later rendering it in an HTML-sensitive context without appropriate output encoding.
This is a stored cross-site scripting flaw mapped to CWE-79, because input is persisted and subsequently interpreted as browser markup or script in another user's session.
The underlying insecure pattern is trusting a user-controlled field label at the presentation layer rather than treating it as text by default and applying context-aware escaping.
Potential impact
- Malicious script execution in a victim's Snipe-IT session
- Exposure of same-origin data accessible to the victim
- Authenticated actions performed with the victim's privileges
- Account or configuration changes made through the victim's session
- Privilege escalation when a more privileged user views the affected asset list
General mitigation guidance
Mitigation generally focuses on making user-controlled labels non-executable by default.
Common defensive patterns include:
- Apply context-aware HTML escaping when rendering custom field names and table headers
- Prefer text-only DOM APIs or templating constructs that do not interpret markup
- Sanitize markup only when rich text is explicitly required, using a narrowly allowlisted policy
- Reduce permission to create or modify custom fields according to least privilege
- Treat stored custom-field values as untrusted across all views and export or preview paths
- Use browser security controls such as an appropriately restrictive Content Security Policy as defense in depth
These controls reduce the likelihood that persisted input can execute in another user's browser.
How teams detect issues like this
Organizations can look for this class of issue through:
- Static analysis rules identifying unescaped values inserted into HTML attributes, titles, or template output
- Code review checks for user-controlled labels passed to HTML-building or DOM-rendering APIs
- Tests that create custom field names containing harmless markup markers and verify they render as text
- Regression tests covering asset lists viewed by users with different privilege levels
- Content Security Policy monitoring for unexpected script violations
- Application logging and review of unusual custom-field creation followed by access to privileged asset lists
Automated application-security and code-review tools may help identify unsafe output contexts, but should be supplemented with framework-aware testing.
