Snipe-IT versions before 8.7.0 fail to properly scope asset acceptance report queries by company, allowing authenticated reports.view users to read pending acceptances across all companies. Attackers can access the unaccepted_assets report page or CSV export to disclose cross-company inventory details and assignee names without per-row access validation.
CVE-2026-86742 is a medium severity vulnerability in grokability's Snipe-IT up to version 8.6.3 where formula elements in CSV exports of the "unaccepted assets" acceptance report are not properly neutralized. This allows an authenticated low-privilege user to inject spreadsheet formulas by setting certain free-text fields to values starting with characters like =, +, -, @, tab, or carriage return. When a user with report viewing privileges exports and opens the CSV in spreadsheet software, the injected formulas can be executed, potentially leading to data exfiltration or command execution. The issue is fixed in version 8.7.0.
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 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 8.6.3 and earlier do not check the return value of Storage::put() when writing the signature PNG and the generated acceptance PDF in Account\AcceptanceController::store(). On filesystem drivers that return false instead of throwing on a write failure (for example the local disk with restrictive permissions, S3 with expired credentials, or a storage backend that is out of quota), execution continues into $acceptance->accept(), which sets accepted_at and the signature_filename/eula_filename fields, creates the 'accepted' action-log entry, and dispatches completion notifications even though the evidence files were never stored. The result is an acceptance record marked complete whose supporting evidence files do not exist, yielding a materially incomplete compliance artifact for EULA acknowledgement or equipment-receipt workflows. The condition is triggered when an authenticated user completes an acceptance while the storage backend is silently failing writes; an attacker cannot directly force the storage backend into that state. Fixed in Snipe-IT 8.7.0.
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.
snipe-it versions before 8.7.0 fail to enforce asset view authorization in the GET /hardware/{asset}/barcode endpoint. Authenticated attackers can iterate asset IDs to retrieve barcodes and enumerate asset tags across tenants, including soft-deleted and cross-company assets.
snipe-it before 8.7.0 contains an incorrect calculation vulnerability in checkout request handling that allows authenticated users to corrupt the assets.requests_counter through duplicate submissions and cancellations without active requests. Attackers can repeatedly call cancel endpoints without active requests to drive the counter negative, or submit duplicate checkout requests to inflate the counter, misrepresenting pending demand in the admin queue.
snipe-it versions before 8.7.0 contain a server-side request forgery vulnerability in the ExternalUrl validation rule that fails to detect IPv6 transition addresses encoding private IPv4 targets. Attackers with super-admin privileges can configure webhook URLs using NAT64, 6to4, or Teredo transition addresses to bypass SSRF guards and access internal services or cloud metadata endpoints.
Snipe-IT before 8.7.1 fails to validate the length of the note field in the POST /account/accept/{acceptance} endpoint, allowing authenticated users to submit unbounded input that reaches synchronous CommonMark rendering. Attackers can submit large note values to exhaust PHP worker CPU and cause denial of service through resource exhaustion in the markdown parsing pipeline.
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 DB_SANITIZE_BY_DEFAULT is false — can execute arbitrary OS commands as the web application's operating-system user, exposing application secrets (including database credentials and APP_KEY) and allowing modification of application-writable files and data. Version 8.7.0 adds the --binary-mode flag to the client invocation.
Snipe-IT is an IT asset/license management system. Prior to 8.6.3, a restricted user can request /api/v1/users/{target_id}/eulas to obtain another user's randomized EULA filename and then download the signed file through /account/stored-eula-file/{filename}. The primary /stored-eula-file/{filename} route correctly denies access, but app/Http/Controllers/ProfileController.php and app/Http/Controllers/Api/UsersController.php do not consistently enforce ownership and target-user authorization. This issue is fixed in version 8.6.3.
Snipe-IT is an IT asset/license management system. Prior to 8.6.3, a company-scoped user in FMCS floater mode can access users whose company_id is null because broad API queries and bulk web actions do not consistently apply isCurrentUserHasAccess. The /api/v1/users and /api/v1/users/{id}/licenses endpoints can expose personal data and assigned licenses, /users/bulkeditsave can modify out-of-scope profiles, and /users/merge can soft-delete users and transfer assigned assets. This issue is fixed in version 8.6.3.
Snipe-IT versions prior to 8.6.3 contain a missing authorization vulnerability (CWE-862) that allows any activated user within a company to access maintenance records of assets without proper permission checks. The vulnerability arises because the controller rendering the maintenance record does not enforce authorization, relying only on company-scoped route-model binding to restrict cross-company access. Disclosed information includes asset tags, suppliers, purchase costs, notes, and dates. This issue is fixed in version 8.6.3.
CVE-2026-61807 is a stored cross-site scripting (XSS) vulnerability in the Snipe-IT IT asset/license management system. Versions prior to 8.6.2 improperly neutralize input when rendering manufacturer or supplier names, allowing crafted input to execute JavaScript in the context of authenticated users viewing certain detail pages. This can potentially expose data or enable actions available to the user's session. The issue is fixed in version 8.6.2.
Snipe-IT versions prior to 8.4.1 contain an improper authorization vulnerability that allows authenticated users with generic asset edit permissions to delete files attached to assets outside their ownership or company assignment. This is due to insecure direct object reference caused by authorization checks against the object class rather than the specific object instance. The issue is resolved in version 8.4.1.
Snipe-IT versions prior to 8.4.1 contain an authorization bypass vulnerability that allows non-superadmin users to move assets across company boundaries by submitting a company_id directly, bypassing multi-tenant isolation controls. This issue is resolved in version 8.4.1.
CVE-2026-55483 is a missing authorization vulnerability in the Snipe-IT IT asset/license management system prior to version 8.6.0. Authenticated users with the users.create permission could create new user accounts with administrative privileges by submitting the admin permission during user creation. The flaw occurs because the store() function strips superuser permissions but does not strip admin permissions. This vulnerability is fixed in version 8.6.0.
Snipe-IT is an IT asset/license management system. Prior to 8.5.0, a user who can edit other users can reset a superadmin's two-factor authentication through app/Http/Controllers/Api/UsersController.php postTwoFactorReset(). The endpoint authorizes update access but does not enforce canEditAuthFields before clearing two_factor_secret and two_factor_enrolled. This issue is fixed in version 8.5.0.
Snipe-IT versions prior to 8.6.1 have a vulnerability in the two-factor authentication implementation. The POST /two-factor endpoint lacks rate limiting or attempt counters, allowing unlimited TOTP guesses with valid credentials. This can lead to unauthorized session creation if a guess is successful. Additionally, two-factor authentication can be disabled without OTP verification under certain configurations, and administrators can reset other users' two-factor secrets via the API. The issue is fixed in version 8.6.1.