Snipe-IT EUVD-2026-31962

Requires an authenticated Snipe-IT account that holds the users.edit permission and network access to the API; the attacker sends a single PATCH to /api/v1/users/{id} with permissions[admin]=1 (or any non-superuser permission key). No user interaction, no non-default configuration, and no special deployment mode are needed - the vulnerable sanitization logic is present by default in all versions before 8.4.1. The principal limiting factor is that a valid users.edit-capable account is a prerequisite (PR:L), so a purely external unauthenticated attacker cannot exploit this directly; note the superuser key remains protected, so escalation tops out at admin, not superuser.

The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H) scores 8.7 High: network-reachable, low complexity, no user interaction, and only low privileges required, with high confidentiality/integrity/availability impact on the vulnerable system. This aligns with the SSVC-style read that exploitation is trivial and automatable once an attacker holds any users.edit-capable account, and technical impact is total (full admin). Countervailing signals: EPSS is only 0.01% (2nd percentile) and the CVE is NOT on CISA KEV, so there is no evidence of active or widespread exploitation - consistent with a bug that requires an existing authenticated foothold rather than an unauthenticated internet-wide primitive. The key limiting factor (a valid account with users.edit) is real and keeps mass-exploitation improbable, but in any multi-tenant or delegated-administration Snipe-IT deployment this is a serious vertical-privilege-escalation path and should be prioritized for patching. This is a genuine priority for affected operators, not merely a high-CVSS-but-low-real-risk issue, though the raw internet exposure is lower than PR:L alone might suggest.

A helpdesk operator granted only the users.edit permission (intended to let them manage user records) sends an authenticated PATCH request to /api/v1/users/{their-own-id} with the body parameter permissions[admin]=1. The server strips only superuser, saves the admin key, and the operator now holds full administrative control over the asset-management platform. No public POC is currently identified, but the single-request nature (AC:L, UI:N) makes exploitation trivial for anyone with the required account.