Snipe-IT vulnerabilities

Snipe-IT prior to 8.6.2 has a stored XSS vulnerability in manufacturer or supplier names. A crafted name can execute JavaScript when an authenticated user views the detail page, potentially exposing data or actions available to that session.

Snipe-IT prior to 8.6.3 allows any activated account to read maintenance records for assets in the same company without asset or maintenance permission. The show() method lacks authorization, disclosing asset tags, suppliers, purchase costs, notes, and dates.

Snipe-IT prior to 8.6.3 has a vulnerability that allows a restricted user to obtain another user's randomized EULA filename and download the signed file. The /stored-eula-file/{filename} and /account/stored-eula-file/{filename} routes do not consistently enforce ownership and target-user authorization.

Snipe-IT prior to 8.6.3 has a vulnerability that allows a company-scoped user in FMCS floater mode to access users whose company_id is null. Broad API queries and bulk web actions do not consistently apply isCurrentUserHasAccess, which can expose personal data and assigned licenses, and allow modification of profiles and soft-deletion of users.

Snipe-IT prior to 8.4.1 allows an authenticated user with generic asset edit permission to delete files attached to assets outside their ownership or company. The destroy() methods authorize against the object class instead of the instance, creating an insecure direct object reference.

Snipe-IT prior to 8.6.0 allows an authenticated user with users.create permission to assign admin permission when creating a user. The store() method strips superuser but not admin permission, allowing the created account to gain administrative privileges.

Snipe-IT prior to 8.4.1 allows a non-superadmin to submit company_id directly in the update() method of BulkAssetsController, bypassing Company::getIdForCurrentUser(). This allows assets to be moved across company boundaries, breaking multi-tenant isolation.

Snipe-IT prior to 8.5.0 allows a user who can edit other users to reset a superadmin's two-factor authentication. The postTwoFactorReset() endpoint authorizes update access but does not enforce canEditAuthFields before clearing two_factor_secret and two_factor_enrolled.

Snipe-IT prior to 8.6.1 allows a user with import permission to overwrite a non-admin user's email via CSV update mode and then request a password reset to take over the account. UserImporter strips unauthorized fields, but ItemImporter restores them from the raw CSV row, and the import path does not require users.edit.

Snipe-IT prior to 8.6.1 has a vulnerability in POST /two-factor with no rate limiting, lockout, or attempt counter, allowing unlimited TOTP guesses. It also allows disabling 2FA without OTP reverification in certain modes.

Snipe-IT before 8.6.0 contains an authorization bypass (insecure direct object reference) in the asset checkout-request cancellation endpoint. The cancel_by_admin and requestingUser values are read from user-controlled URL path segments and used without a server-side authorization check, so any authenticated, low-privileged user can supply a non-empty cancel_by_admin value to bypass the request-ownership check and cancel another user's pending checkout request. Because asset and user identifiers are sequential integers, an attacker can enumerate them to cancel every pending checkout request, disrupting the asset-request workflow. This is fixed in Snipe-IT 8.6.0.

In Snipe-IT prior to version 8.6.2, the unaccepted-assets report delete endpoint authorizes only reports.view and deletes CheckoutAcceptance::pending()->find($acceptanceId) by global ID without checking access to the related checkoutable asset. This allows a reports user in one company to delete pending checkout acceptance records for another company.

In Snipe-IT prior to version 8.6.2, the default.blade.php renders header_color and related branding color settings inside a CSS style block with insufficient HTML escaping for the CSS context. This allows a superadmin to inject arbitrary CSS that affects authenticated users on subsequent page loads when Content Security Policy is disabled.

In Snipe-IT prior to version 8.6.2, a vulnerability exists in the legacy single-seat license checkin flow. The endpoint authorizes the action using the checkout permission instead of the checkin permission, allowing a user with license assignment rights but without unassignment rights to directly reclaim a license seat assigned to another user or asset.

In Snipe-IT prior to version 8.6.1, the Importer API endpoint allows a user with CSV import capabilities and a valid API key to overwrite the created_by value of an import file, enabling unauthorized modification of import ownership metadata.

In Snipe-IT prior to version 8.6.2, an authenticated user with import and assets.update permissions can place a path traversal string in an asset image field through CSV import and then trigger image deletion, allowing deletion of arbitrary files accessible to the server process.

Snipe-IT prior to version 8.6.2 has a vulnerability due to insufficient sanitization of uploaded SVG files. A low-privilege user can upload active XHTML or XML content that is later served same-origin and executes JavaScript in a viewer's browser.

In Snipe-IT prior to version 8.6.2, the UsersController::show() and printInventory() methods only authorize user viewing before loading and rendering assigned license, accessory, and consumable relationships. This allows an authenticated user with only users.view permission to see inventory and cost/order metadata from modules that direct permissions would otherwise deny.

A vulnerability in Snipe-IT prior to version 8.6.2 allows an attacker to control the redirect after a user edit action. By setting the Referer header, the attacker can force the application to redirect the victim to an external, malicious site.

Snipe-IT prior to 8.5.0 stores the User-Agent header from requests in the action log and writes it to the Activity Report CSV without formula escaping. This allows a low-privileged authenticated user to inject a malicious formula that may execute when the CSV is opened in spreadsheet software.

In Snipe-IT prior to version 8.6.0, the UsersController::update() method processes a missing permission request field through NormalizePermissionsPayloadAction and PreserveUnauthorizedPrivilegedPermissionsAction in a way that can overwrite a target user's permissions with a sparse result. This allows an administrator updating another administrator, or a user with users.edit updating a regular account, to remove the target's administrative or granular permissions.

A vulnerability in Snipe-IT prior to version 8.6.2 allows an authorized user to move a maintenance record to an asset outside their company scope. This occurs because PATCH or PUT requests to /api/v1/maintenances/{maintenance_id} do not re-authorize the newly supplied asset_id.

Snipe-IT prior to version 8.6.2 has a vulnerability in the POST /api/v1/kits/{kit_id}/licenses endpoint, allowing a low-privilege user to bind a license to a kit without proper authorization. Access to the license object is not validated, enabling unauthorized license association.

Snipe-IT prior to version 8.6.0 has a vulnerability in the POST /account/request/{itemType}/{itemId}/{cancel_by_admin?}/{requestingUser?} endpoint, where the cancel_by_admin parameter is accepted without proper authorization. An authenticated user can supply a victim user ID and silently cancel that user's pending asset requests.

In Snipe-IT prior to version 8.5.0, the displaySig method in ActionlogController lacks sanitization of the filename parameter, allowing an authenticated attacker to traverse outside the intended directory and read arbitrary files accessible to the web server process.

In Snipe-IT prior to 8.6.2, with Full Multiple Companies Support and scope_locations_fmcs enabled, the API location creation endpoint detects a parent-child company mismatch but does not abort, allowing creation of a child location under a parent from a different company.

Snipe-IT prior to 8.6.2 did not sanitize javascript: URIs in Markdown hyperlinks, allowing a user with assets.edit permission to place a malicious link in a markdown-textarea custom field. When another user opens the asset detail page and clicks the link, arbitrary JavaScript executes.

In Snipe-IT prior to 8.6.2, an authenticated non-admin user with users.view and users.edit but without users.delete can directly POST to /users/bulksave with delete_user=1 because BulkUsersController::destroy() authorizes only update, allowing the user to soft-delete another non-admin user.

In Snipe-IT prior to version 8.6.2, the Accessories API create path mass-assigns request parameters to the Accessory model, including the company_id field. This allows a low-privileged authenticated user from one company to create accessory records under another company when Full Multiple Companies Support is enabled.

In Snipe-IT prior to version 8.6.1, the GET /api/v1/{object}/selectlist endpoint lacks authorization. Any logged-in user, regardless of permissions, can retrieve a paginated list of all user accounts, exposing usernames, display names, employee numbers, and user IDs.

Snipe-IT before version 8.6.1 has a vulnerability where authorization is missing before generating a temporary URL for images stored in S3. An authenticated user who knows a signature filename can obtain a 5-minute signed S3 URL because the S3 branch returns before the `authorize()` call used by the local-file branch.

Snipe-IT before version 8.6.0 contains a vulnerability that allows a non-admin user with only the granular `users.edit` permission to lock every admin out by editing the `activated` and `ldap_import` flags. Version 8.6.0 contains a patch.

Snipe-IT prior to version 8.4.1 has an open redirect vulnerability via an unvalidated HTTP Referer header stored in a session variable. Attackers can redirect users to malicious sites.

Snipe-IT is an IT asset/license management system. Prior to 8.4.1, an authenticated user with only users.edit permission can escalate their own privileges to admin by sending a PATCH request to /api/v1/users/{id} with permissions[admin]=1. The API controller only strips the superuser key from the permissions array, allowing admin and all other permission keys to be set by any user who can update users. This vulnerability is fixed in 8.4.1.

Snipe-IT prior to version 8.4.1 has an XSS vulnerability in the notes column for users with component view access. Insufficient escaping allows script injection.

Cross-Site Scripting vulnerability in Snipe-IT asset management system versions 8.3.0 through 8.3.1. An authenticated attacker with minimal privileges can inject arbitrary JavaScript code via the "Name" and "Surname" fields. The code executes when the Activity Report or a modified profile is viewed by other users with sufficient permissions, provided the profile has no Display Name set.

Snipe-IT before version 8.3.4 is vulnerable to stored XSS via the Locations "Country" field. A low-privileged authenticated user can inject JavaScript that executes in another user's session.

A stored XSS vulnerability in Snipe-IT before version 8.3.4 allows a low-privileged authenticated user to inject JavaScript that executes in an administrator's session, enabling privilege escalation.