CVE-2026-86755: Snipe-IT 4.2.0 through 8.6.3 Permission Bypass via OAuth
Snipe-IT versions 4.2.0 through 8.6.3 expose Laravel Passport's auto-registered personal-access-token routes (GET, POST, DELETE /oauth/personal-access-tokens) with only 'web' and 'auth:web' middleware, without the self.api permission gate that Snipe-IT enforces on its own token endpoints (/account/api and /api/v1/account/personal-access-tokens). Any user with a valid web session and the corresponding CSRF token can POST to /oauth/personal-access-tokens and mint a long-lived bearer token for their own account, even when an administrator has denied the self.api permission. The issued token is still subject to existing per-endpoint authorization policies, so this is not a privilege escalation; it defeats the administrative control intended to block API/scripted access at the user's own permission level. Fixed in 8.7.0 (commit 3f74b8c), which registers overriding routes wrapped in the can:self.api middleware.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Snipe-ITto a version that resolves this vulnerability.Fixed in 8.7.0Patch 3f74b8c - Compensating control
For Snipe-IT versions 4.2.0 through 8.6.3, restrict/limit access to the Laravel Passport personal-access-token endpoints (/oauth/personal-access-tokens with GET/POST/DELETE) so users cannot mint long-lived bearer tokens via these auto-registered routes when admin has denied self.api.
Event History
Frequently Asked Questions
Who can exploit this issue?
Any authenticated Snipe-IT user with a valid web session and the corresponding CSRF token can exploit it. The user does not need the self.api permission that would normally be required to create an API token.
Does this give the attacker additional Snipe-IT privileges?
No. The minted bearer token remains subject to existing authorization policies for each API endpoint, so it operates at the user’s existing permission level. The impact is bypassing the administrator’s ability to prevent that user from using API or scripted access.
Which deployments are affected, and what is the fix?
Snipe-IT versions 4.2.0 through 8.6.3 are affected. Version 8.7.0 fixes the issue by registering overriding personal-access-token routes protected by the can:self.api middleware.
How can an administrator determine whether the bypass may have been used?
Review for bearer tokens created through the /oauth/personal-access-tokens endpoints by accounts that were denied the self.api permission. Those routes permit GET, POST, and DELETE requests and are distinct from Snipe-IT’s intended token-management endpoints.