Pizzastev3

Laravel Passport's auto-registered personal-access-token routes (GET, POST, DELETE '/oauth/personal-access-tokens*') are exposed using only 'web' and 'auth:web' middleware. This bypasses the `self.api` permission gate that is normally enforced on other token endpoints such as '/account/api' and '/api/v1/account/personal-access-tokens'. Consequently, any user with a valid web session and a valid CSRF token can send a POST request to '/oauth/personal-access-tokens' to generate a long-lived bearer token for their own account, even if an administrator has explicitly denied the `self.api` permission. While the resulting token remains subject to existing authorization policies and does not grant higher privileges, it bypasses administrative controls designed to prevent API or scripted access for specific users.

An authorization bypass exists in Livewire components that enforce authorization only at the route level rather than within component lifecycle methods. An authenticated attacker can replay signed component snapshots via the 'POST /livewire/update' endpoint to invoke protected methods. This allows for privilege escalation, enabling the creation of OAuth clients, minting of personal access tokens, and access to sensitive administrative data.

Authenticated users can bypass administrative restrictions to create checkout requests for asset models that are not marked as requestable. This occurs because the application fails to validate the requestable flag when processing requests via the 'POST /account/request/asset model/{modelId}' endpoint.

Insufficient access control on Laravel Passport OAuth client management routes allows any authenticated user to register OAuth clients using redirect URIs controlled by an attacker. This can lead to a scenario where administrators are deceived into approving consent screens, enabling the exchange of authorization codes for bearer tokens. These tokens can inherit full administrative API permissions with a validity period of up to 40 years.

A race condition exists in the asset checkout paths. The functions `ApiAssetsController::checkout()` and `AssetsAssetCheckoutController::store()` call `Asset::availableForCheckout()` outside the mutation path and subsequently invoke `Asset::checkOut()` without implementing a row lock or re-verifying availability. Consequently, two concurrent checkout requests for the same available asset can both be processed as successful. This results in duplicate checkout-history rows, a doubled `checkout counter`, and two `CheckoutableCheckedOut` events for a single-assignment asset, which corrupts the audit trail and utilization/reconciliation reporting. The final `assigned to` value remains singular, leaving the visible assignment intact. Exploitation requires an authenticated session with the `assets.checkout` permission or superuser privileges, combined with precise concurrent timing.

An incorrect calculation issue in checkout request handling allows authenticated users to corrupt the `assets.requests counter`. This occurs when users submit duplicate checkout requests or repeatedly call cancel endpoints without having active requests. Such actions can inflate the counter or drive it into negative values, leading to a misrepresentation of pending demand within the admin queue.

Authenticated attackers can retrieve barcodes and enumerate asset tags across tenants, including soft-deleted and cross-company assets. This occurs because the application fails to enforce asset view authorization at the 'GET /hardware/{asset}/barcode' endpoint when processing the `asset` variable.

Authenticated users can cause a denial of service by submitting unbounded input through the `note` field in the 'POST /account/accept/{acceptance}' endpoint. This occurs because the application fails to validate the length of the input before it reaches the synchronous CommonMark rendering process, which is a system for converting markdown text into HTML. Large values in the `note` field can exhaust PHP worker CPU resources during the markdown parsing pipeline.