Snipe-IT versions before 8.7.0 contain a broken access control vulnerability in AssetModelPolicy where the files() method cascades from assets.files permission, allowing authenticated users to upload and delete file attachments on Asset Model records without the required models.files permission. Attackers with only assets.files permission can mutate shared model file attachments across company boundaries and bypass the dedicated models.files permission intended to restrict file management on the shared Asset Model catalog.

Snipe-IT versions before 8.7.0 fail to authorize the POST /hardware/history endpoint, allowing any authenticated user to reassign arbitrary assets and modify audit logs. Attackers can submit a CSV file to reassign assets across companies and inject fraudulent audit trail entries, compromising inventory integrity and accountability.

Snipe-IT versions before 8.6.2 contain an authorization bypass vulnerability in checkout-acceptance report actions when Full Multiple Company Support is enabled. Authenticated users with reports.view permission can enumerate sequential acceptance IDs and soft-delete or trigger reminder emails for acceptances belonging to other companies by exploiting a null check on the legacy users.companyid column.

snipe-it versions before 8.6.3 contain an authorization bypass vulnerability in the bulk delete functionality that allows restricted users to soft-delete users outside their authorized scope. Attackers can include unauthorized user IDs in bulk delete requests to bypass instance-level restrictions and modify or disable accounts they should not access.

Snipe-IT versions before 8.7.0 fail to apply company scope filtering to the GET /hardware/requested endpoint when Full Multiple Company Support is enabled, allowing authenticated users with assets.view permission to read pending asset requests from all companies. Attackers can retrieve cross-tenant data including requested asset names, requester display names and profile links, locations, and expected check-in dates without parameter manipulation.

Snipe-IT before 8.7.0 does not apply the CheckUserIsActivated middleware to the api middleware group in app/Http/Kernel.php, and deactivating a user does not revoke that user's Passport personal access tokens. As a result, although a deactivated account is correctly refused at web login, its existing API token continues to authenticate and to grant read and write access to the REST API (assets, users, licenses, etc.) at the account's prior permission level until the token expires. A deactivated account that retains user-management permissions can re-activate itself through the API, permanently defeating the deactivation control.

snipe-it versions before 8.7.0 contain an authorization bypass vulnerability in location print endpoints that fails to enforce per-model authorization checks. Authenticated attackers with location view permission can access printassigned and printallassigned endpoints to retrieve related users, assets, accessories, consumables, and components regardless of their individual model permissions.

Snipe-IT before 8.7.0 streams the SQL entry from an uploaded backup archive directly into the MySQL/MariaDB command-line client (mysql) without the --binary-mode flag, so the client interprets lines beginning with backslash commands such as \! as local shell commands. An authenticated superadministrator who uploads a crafted ZIP backup (POST /admin/backups/upload) and triggers a restore (POST /admin/backups/restore/{filename}) without the optional clean sanitizer parameter — which is not applied by default because DBSANITIZEBYDEFAULT is false — can execute arbitrary OS commands as the web application's operating-system user, exposing application secrets (including database credentials and APPKEY) and allowing modification of application-writable files and data. Version 8.7.0 adds the --binary-mode flag to the client invocation.

Snipe-IT before 8.7.0 fails to check the return value of Storage::delete() in UploadedFilesController::destroy() and Api\\UploadedFilesController::destroy(), allowing deletion requests to report success while files remain on disk. Administrators performing attachment deletions receive success responses and see files hidden from listings, but the physical files persist on disk and remain accessible to anyone with filesystem or backup access.

Snipe-IT versions before 8.7.0 fail to sanitize the category EULA text field before rendering it in checkout confirmation emails. Attackers with low-privilege permissions can inject markdown image syntax or raw HTML img tags pointing to local files or remote URLs, which the mail auto-embed library resolves server-side and returns as email attachments, exfiltrating sensitive files like .env credentials and enabling SSRF attacks.

Snipe-IT versions before 8.7.0 wipe the database before validating the uploaded backup archive in the restore endpoint. Superusers uploading corrupted or invalid zip files trigger permanent data loss with no recovery path or rollback mechanism.

snipe-it versions before 8.7.0 fail to enforce per-instance FMCS scoping in asset audit endpoints, relying solely on query-layer filtering instead of policy-layer authorization checks. Attackers with valid sessions and assets.audit permissions could write audit log entries against cross-company assets if the query-layer scope were bypassed or refactored.

Impact The table component derives data-selected-count-id from the component $name value. On manufacturer and supplier detail pages, stored manufacturer or supplier names are passed into affected table components as that name value. The client-side JavaScript later reads the browser-decoded data-selected-count-id, uses it as a selector, and concatenates countId.substring(1) directly into an HTML string passed to jQuery .after().

Affected commit:

b224cc636c6780386e3f73f03d1171f52ab4c37a

Example payload for a manufacturer or supplier name: x[foo="><svg/onload=alert(1)>"]>

The issue appears to involve the following flow:

Stored supplier/manufacturer name -> table component data-selected-count-id -> browser decodes the attribute -> JavaScript reads countId -> countId is used as a selector -> countId.substring(1) is concatenated into HTML -> jQuery .after() inserts attacker-controlled markup -> JavaScript executes in the victim's browser

Potential impact includes arbitrary JavaScript execution in the browser of an authenticated Snipe-IT user who views the affected supplier or manufacturer detail page. If the victim has elevated privileges, this may allow access to data or actions available to that user's session.

Patches Patched in https://github.com/grokability/snipe-it/commit/d12ad3d53869443b96b663ba3ce2673ef343da71

Snipe-IT versions before 8.7.0 contain a CSS injection vulnerability in the Custom CSS field due to incomplete sanitization that reverses HTML encoding on greater-than and double-quote characters. Superusers can plant malicious CSS payloads using @import and url() references to exfiltrate CSRF tokens from other superusers via attribute-selector rules, enabling account takeover.

Grokability Snipe-IT before 8.1.0 has incorrect authorization for accessing asset information.

Snipe-IT before 7.0.10 allows remote code execution (associated with cookie serialization) when an attacker knows the APPKEY. This is exacerbated by .env files, available from the product's repository, that have default APPKEY values.

An issue in Snipe-IT v.7.0.13 build 15514 allows a low-privileged attacker to modify their profile name and inject a malicious payload into the "Name" field. When an administrator later accesses the People Management page, exports the data as a CSV file, and opens it, the injected payload will be executed, allowing the attacker to exfiltrate internal system data from the CSV file to a remote server.

Snipe-IT through 6.0.14 allows attackers to check whether a user account exists because of response variations in a /password/reset request.

Snipe-IT before 6.0.14 is vulnerable to Cross Site Scripting (XSS) for View Assigned Assets.

Stored Cross-Site Scripting (XSS) vulnerability in Snipe-IT - v7.0.13 allows an attacker to upload a malicious XML file containing JavaScript code. This can lead to privilege escalation when the payload is executed, granting the attacker super admin permissions within the Snipe-IT system.

Cross-Site Request Forgery (CSRF) in GitHub repository snipe/snipe-it prior to v.6.2.3.

Cross-site Scripting (XSS) - Stored in GitHub repository snipe/snipe-it prior to v6.2.2.

snipe-it is vulnerable to Cross-Site Request Forgery (CSRF)

snipe-it is vulnerable to Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')

snipe-it is vulnerable to Improper Access Control

Admin users on the external network can perform blind POST-based SSRF (issue requests on behalf of the server into the internal network) via the Slack Integration. This vulnerability is capable of port-scanning of the internal network, issue POST requests to web servers on the internal network which can be escalated to higher-impact.

snipe-it is vulnerable to Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')

Snipe-IT before 4.6.14 has XSS, as demonstrated by logmeta values and the user's last name in the API.

snipe-it is vulnerable to Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')

snipe-it is vulnerable to Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')