Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.4",
  "pubDate": "2026-09-09T14:17:24.737Z",
  "pubdate": "2026-09-09T14:17:24.737Z",
  "executiveSummary": "Snipe-IT versions 4.2.0 through 8.6.3 contain a security oversight where Laravel Passport's default personal-access-token routes are improperly secured.\nThe vulnerability involves the failure to apply necessary authorization middleware to standard OAuth2 routes, allowing authenticated web users to bypass administrative restrictions.\nSpecifically, users can mint long-lived personal access tokens (PATs) despite explicit administrative revocation or denial of 'self.api' permissions intended to block programmatic access.\nThis represents a failure in access control enforcement where the application's internal policy enforcement (gate) is bypassed by the underlying framework's auto-registered endpoints.\nThe impact is limited to unauthorized creation of API tokens for the attacker's own account; it does not constitute privilege escalation as the tokens remain bound by the user's existing scope and permissions.\nRisk implications include the circumvention of organization-wide security policies regarding API usage and the potential for persistent, automated access by users meant to be restricted to the web interface.\nExploitation requires a valid web session and a valid CSRF token, making it a post-authentication attack vector.",
  "technicalDetails": "The root cause of this vulnerability lies in the default behavior of Laravel Passport, which auto-registers API routes for managing OAuth personal access tokens. In Snipe-IT versions 4.2.0 through 8.6.3, these routes (specifically /oauth/personal-access-tokens) are exposed with only basic 'web' and 'auth:web' middleware.\nWhile Snipe-IT implements custom logic to restrict API access through a specific 'self.api' permission gate—applied to standard endpoints like /account/api and /api/v1/account/personal-access-tokens—the Passport-default routes remain unprotected by this gate.\nAn attacker possessing a valid, low-privileged web session can exploit this by crafting an HTTP POST request to the /oauth/personal-access-tokens endpoint. Because the endpoint only checks for a standard authenticated session and a valid CSRF token, the application processes the request and mints a new personal access token for the user.\nThe attack flow is as follows: 1) The attacker authenticates normally via the web interface. 2) The attacker extracts a valid CSRF token from the session. 3) The attacker submits a POST request to /oauth/personal-access-tokens with the required parameters to generate a new token. 4) The server, failing to verify the 'self.api' permission gate, returns a valid bearer token.\nAlthough the resulting token is still subject to standard authorization policies per individual API endpoint (meaning the user cannot perform actions they were not already permitted to perform via the UI), the ability to mint a token defeats the administrative intent of disabling programmatic access. This effectively provides the user with an easier mechanism for scriptable interaction with the Snipe-IT API, bypassing the intended control surface.\nThe vulnerability was addressed in version 8.7.0 (commit 3f74b8c) by explicitly overriding the Passport route registration. By wrapping these routes in the 'can:self.api' middleware, Snipe-IT ensures that the application-level permission gate is evaluated before any token generation occurs, thus synchronizing the OAuth route security with the rest of the application's API authorization model."
}