Rajib-Mahmud

An authenticated user with file-management access can upload malicious XML and XSLT (Extensible Stylesheet Language Transformations) attachments. The API endpoint 'GET /api/v1/{object type}/{id}/files/{file id}' fails to apply a safe-inline allowlist when the `inline` parameter is set to `true`. This allows the browser to process an attacker-controlled xml-stylesheet reference, leading to the execution of arbitrary JavaScript within the Snipe-IT origin. If an authorized victim opens the attachment URL, the script can read same-origin data and perform authenticated actions using the victim's privileges, potentially leading to administrative account compromise and exposure of sensitive asset, user, and license information.

An authorization bypass exists in the bulk delete functionality. This issue allows restricted users to perform a soft-delete on users outside their authorized scope by including unauthorized user IDs in bulk delete requests, enabling them to modify or disable accounts they are not permitted to access.

An authorization bypass exists in the REST API timesheet collection endpoint. The system fails to enforce activity-team access controls, allowing users with the `view other timesheet` permission to list timesheets associated with activities restricted to teams they are not members of, which bypasses intended data isolation.

An issue exists where a company-scoped user in FMCS floater mode can access users with a null `company id` because the `isCurrentUserHasAccess` check is not consistently applied during broad API queries and bulk web actions. This allows for the exposure of personal data and assigned licenses via the '/api/v1/users' and '/api/v1/users/{id}/licenses' endpoints. Additionally, the '/users/bulkeditsave' endpoint can be used to modify profiles outside the user's scope, and the '/users/merge' endpoint can be used to transfer assigned assets and soft-delete users.

An issue exists where a restricted user can obtain another user's randomized EULA filename by requesting the '/api/v1/users/{target id}/eulas' endpoint. Subsequently, the signed file can be downloaded via the '/account/stored-eula-file/{filename}' endpoint. This occurs because `app/Http/Controllers/ProfileController.php` and `app/Http/Controllers/Api/UsersController.php` do not consistently enforce ownership and target-user authorization, despite the primary '/stored-eula-file/{filename}' route correctly denying access.