Snipe-IT EUVD-2026-74939

Exploitation requires possession of an existing, unexpired Laravel Passport personal access token issued to the target account prior to deactivation, and that token must not have been manually revoked (revoked = 1) in the oauth_access_tokens database table. This is strictly a post-deactivation or insider threat vector: the attacker must have previously authenticated to Snipe-IT and generated or obtained an API token. The most severe escalation (self-reactivation via PATCH /api/v1/users/{id} with {"activated": 1}) additionally requires the deactivated account to have previously held the users.edit permission. Accounts whose tokens have expired, been explicitly revoked, or were never issued are not affected. Network access to the Snipe-IT REST API endpoint is required; if the API is firewalled to internal networks only, external exploitability is reduced but insider threat scenarios remain fully viable.

The CVSS 4.0 score of 8.6 (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N) accurately reflects the threat model: network-accessible, low complexity, requiring only a pre-existing low-privilege bearer token, with high confidentiality and integrity impact. The gating prerequisite - an unexpired, non-revoked Passport token - confines exploitation to insider or post-employment scenarios rather than opportunistic external attacks. Real-world risk is highest in organizations with long-lived API tokens, which is common in Snipe-IT deployments where staff generate personal access tokens for automation scripts. The self-reactivation escalation path elevates the severity disproportionately to PR:L: even a mid-sized IT operations team in swidnica would face a plausible offboarding failure where a departing admin re-enables their account before token rotation occurs. No CISA KEV listing is present and no public exploit code has been identified, making broad automated exploitation unlikely; however, targeted post-employment misuse is a realistic and potentially undetected threat.

A departing employee was deactivated in Snipe-IT but had previously generated a long-lived Passport personal access token for use in an automation script. Using that token from any network-accessible client, the employee sends PATCH /api/v1/users/{own_id} with {"activated": 1}, which succeeds because the api middleware group never checks activation status. Once re-activated, the account functions normally for both web and API access with no indication to administrators that the deactivation was reversed. No public exploit code has been identified; the attack requires only a standard HTTP client and the attacker's own token.