Snipe-IT EUVD-2026-42998

Exploitation requires an active, authenticated Snipe-IT session for an account that holds the license checkout (assign) permission but has NOT been granted the checkin (unassign) permission. The attacker must directly target the legacy single-seat checkin endpoint - the newer checkin flow uses the correct permission check and is not affected. The flaw is limited to Snipe-IT instances running versions prior to 8.6.2. Exploitation is further bounded by whether the Snipe-IT instance is internet-facing or restricted to an internal network; internal restriction meaningfully reduces exposure to external attackers. No guest or unauthenticated access path exists. The impact is confined to license seat management - an attacker cannot escalate beyond reclaiming license assignments.

The CVSS 4.0 vector (score 5.3, Medium) accurately reflects the constrained blast radius: integrity impact is low and scoped only to the vulnerable system (VI:L, SI:N), and there is no confidentiality or availability impact. The attack requires low-privilege authentication (PR:L), which limits opportunistic or unauthenticated exploitation. No EPSS data was provided, and the vulnerability is absent from the CISA KEV catalog, indicating no confirmed active exploitation at time of analysis. No public POC exists. Real-world risk is therefore moderate and contextual: in organizations relying on Snipe-IT's role-based permission model to enforce separation between license-assignment and license-reclamation duties - for example, as a compliance or audit control - this flaw directly undermines that boundary. For environments without such separation requirements, the practical operational impact is narrower. The self-contained scope within license management functionality prevents this from being leveraged for broader system compromise.

An authenticated Snipe-IT user with only license-checkout (assignment) rights identifies the legacy single-seat checkin endpoint URL - discoverable via source code inspection or API enumeration. By crafting a direct HTTP request to that endpoint referencing a license seat assigned to another user or asset, the attacker successfully triggers a checkin, reclaiming the seat without ever holding the checkin permission. No public exploit code exists, but the attack requires no special tooling beyond an authenticated browser session or a simple HTTP client.