Snipe-IT vulnerabilities

Snipe-IT before 8.7.0 allows an authenticated user with file-management access to upload XML and XSLT attachments and request them with inline=true. The browser can process an attacker-controlled xml-stylesheet reference and execute JavaScript generated by the stylesheet in the Snipe-IT origin. A victim must open the attachment URL, after which the script can read same-origin data and perform authenticated actions with the victim's privileges.

Snipe-IT before 8.7.0 allows a password-authenticated session for an account with self.api permission to reach the personal-access-token API flow before completing the account's second-factor challenge because CheckForTwoFactor is enforced in the web middleware group but not the API middleware group. The resulting token can read and modify resources with the victim's permissions and, for an administrator, can reach the users/two_factor_reset endpoint, allowing account takeover.

Snipe-IT before 8.7.0 allows a user with customfields.create permission to store markup in CustomField.name, which is assigned as an unescaped bootstrap-table header title. When another user opens an asset-list page, the stored markup executes on page load in that user's session, potentially exposing same-origin data and performing authenticated actions, including privilege escalation.

Snipe-IT's predefined kit checkout path does not enforce Full Multiple Company Support (FMCS) tenant isolation on the checkout target. Unlike the single, bulk, API, accessory, license and consumable checkout paths, App\Services\PredefinedKitCheckoutService never calls $item->canCheckoutTo($target); it only performs the actor-vs-item policy check and an availability check before persisting the checkout. With FMCS enabled, a non-superuser who belongs to at least two companies and holds the assets.checkout permission can POST to /kits/{kit}/checkout with a user_id belonging only to company B and have a company-A asset (and likewise kit licenses, consumables and accessories) assigned to that user, bypassing the company-mismatch check. The issue is fixed in Snipe-IT 8.7.2.

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 through version 8.6.3 fails to perform object-level authorization in the updateLicense, updateConsumable, updateAccessory, and updateModel endpoints and in the storeModel endpoint for Predefined Kits. The existing check authorizes only the parent Predefined Kit (update on PredefinedKit) and not the child object being attached. As a result, an authenticated user holding only the kits.edit permission can attach a License, Consumable, Accessory, or Asset Model that they are otherwise denied (HTTP 403) from reading directly to a Predefined Kit, and the kit relation index then discloses the attached object's name back to that low-privilege user. This is the update-path and storeModel counterpart to CVE-2026-55478, which fixed only the storeLicense, storeConsumable, and storeAccessory methods in 8.6.2. Note that updateModel was code-vulnerable in 8.6.3 but not reachable in practice because a route-name typo bound the route to a nonexistent controller method, causing HTTP 500 responses. The issue is fixed in Snipe-IT 8.7.0.

Snipe-IT before version 8.7.0 contains a stored cross-site scripting vulnerability in DepartmentPresenter::formattedNameLink() where department names are rendered unescaped in the fallback branch for users without departments.view permission. Users with departments.edit permission can inject malicious scripts into department names that execute in the browsers of all department members when they load their My Assets page.

Snipe-IT before version 8.7.0 fails to HTML-escape the employee_num field in the acceptance PDF generator, allowing attackers with users.edit permission to inject img tags into TCPDF's writeHTML() function. Attackers can craft a malicious employee_num value containing an img tag with an arbitrary HTTP(S) URL to trigger server-side requests to internal services, cloud metadata endpoints, or external targets when a victim signs an asset acceptance.

Snipe-IT before 8.7.0 fails to validate username case sensitivity during SAML authentication, allowing attackers to authenticate as different users by registering IdP accounts with accent or case variants of victim usernames. Attackers can exploit the default utf8mb4_unicode_ci database collation to bypass username matching and achieve account takeover through federated login paths including SAML, LDAP, and OAuth.

Snipe-IT before version 8.7.0 contains an improper ownership management vulnerability in the consumables checkout API endpoint that records the checkout target user's id in the created_by column instead of the authenticated caller's id. Authenticated attackers with consumables.checkout permission can perform checkouts that result in misattributed audit trail entries in the consumables_users pivot table, obscuring which operator performed the action.

Snipe-IT before 8.7.0 fails to validate soft-deleted state in API checkout endpoints, allowing authenticated users with checkout permissions to bind live inventory to trashed targets. Attackers can submit POST requests to hardware, component, or consumable checkout endpoints with soft-deleted user, asset, or location IDs to create orphaned references that corrupt the asset ledger and audit trails.

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 versions up to and including 8.6.3 contain a race condition (TOCTOU) in the consumable checkout API endpoint (POST /api/v1/consumables/{consumable_id}/checkout). The requested quantity is validated against the number of remaining units before the database transaction begins, and the transaction then creates the checkout records without locking the consumable row or re-checking availability. An authenticated user with permission to check out consumables can submit concurrent checkout requests for the same consumable so that both requests pass the availability check and succeed, over-allocating stock and driving the remaining inventory negative (e.g., a consumable with 1 remaining unit ends at -1 after two concurrent 1-unit checkouts). The issue is fixed in 8.7.0, which re-fetches the parent row under lockForUpdate inside the transaction and re-validates availability.

Snipe-IT versions before 8.7.0 fail to enforce checkout authorization when assignment fields are submitted to the asset update endpoint. Authenticated users with edit permission but explicitly denied checkout permission can reassign assets, bypass check-in procedures, and alter custody records by submitting assigned_user, assigned_asset, or assigned_location parameters to PATCH /api/v1/hardware/{id}.

Snipe-IT through 8.6.4 (fixed in 8.7.0) does not enforce the components.view permission on the authenticated endpoint GET /api/v1/hardware/<asset-id>/assigned/components. The endpoint authorizes only assets.view on the parent asset before returning linked component details; the components.view check is applied only to the response's available_actions.view flag and not to the returned data. As a result, an authenticated user holding only assets.view can enumerate component IDs, names, assigned quantities, and notes that are otherwise protected — the direct GET /api/v1/components/<id> endpoint correctly returns 403 Forbidden for such users.

Snipe-IT versions >= 7.0.12 and <= 8.6.3 contain an authorization bypass in the Livewire importer component. Any authenticated non-superuser holding the import permission could view every Import record and load another user's preview data, exposing sensitive information like personal data, asset serial numbers and license keys. Impact is limited to preview data; superusers unaffected. Fixed in 8.7.0.

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 versions 8.2.0 through 8.6.x (fixed in 8.7.0) contain an incorrect authorization flaw in app/Http/Controllers/Users/UsersController::update(). The single-user edit route assigned the activated field from the request payload before evaluating the canEditAuthFields authorization gate, so an authenticated non-admin user holding the users.edit permission in the target's company scope can submit a full valid PUT request to /users/{id} and toggle the activated flag on any user, including admin and superuser accounts. Deactivating an admin locks that account out of the application until another admin or superuser re-enables it. Only the activated field is affected; username, email, password and permissions remain protected by the gate, no data is disclosed, and the API (Api\UsersController::update) and bulk-edit paths are not affected.

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 before 8.7.0 fails to properly enforce the viewKeys authorization gate in CSV export and API index endpoints, allowing authenticated users with only licenses.view permission to access product keys. Attackers can download all license keys in bulk via CSV export or validate candidate keys through API response discrepancies without needing the viewKeys permission.

Snipe-IT before 8.7.0 fails to properly gate access to encrypted custom-field values in asset form templates for listbox, textarea, markdown-textarea, and date/datetime picker elements. Authenticated users with assets.edit, assets.checkin, assets.checkout, or assets.audit permissions can read plaintext encrypted custom field values by opening asset forms, bypassing the assets.view.encrypted_custom_fields permission check.

Snipe-IT 8.5.0 through 8.6.3 contains an open redirect vulnerability in its SAML assertion-consumer endpoint (SamlController::acs, POST /saml/acs). The endpoint wrote the RelayState POST parameter directly into Laravel's url.intended session key with only CR/LF characters stripped, and LoginController later issued redirect()->intended(), which passes an absolute URL through to the Location header unchanged. An unauthenticated attacker who induces a user of a SAML-SSO-enabled instance to visit a crafted IdP-initiated SSO link can therefore cause the victim's browser to be redirected to an arbitrary absolute external URL immediately after a successful authentication, which the advisory notes facilitates credential-harvesting phishing. No account on the target instance and no compromise of the identity provider are required. Only deployments with SAML SSO enabled are affected. Fixed in 8.7.0 (commit d30b73d, PR #19386), which validates RelayState via a new Helper::sameOriginUrl check before storing it.

Snipe-IT versions 4.2.0 through 8.6.3 expose Laravel Passport's auto-registered personal-access-token routes (GET, POST, DELETE /oauth/personal-access-tokens*) with only 'web' and 'auth:web' middleware, without the self.api permission gate that Snipe-IT enforces on its own token endpoints (/account/api and /api/v1/account/personal-access-tokens). Any user with a valid web session and the corresponding CSRF token can POST to /oauth/personal-access-tokens and mint a long-lived bearer token for their own account, even when an administrator has denied the self.api permission. The issued token is still subject to existing per-endpoint authorization policies, so this is not a privilege escalation; it defeats the administrative control intended to block API/scripted access at the user's own permission level. Fixed in 8.7.0 (commit 3f74b8c), which registers overriding routes wrapped in the can:self.api middleware.

Snipe-IT before 8.7.0 fails to properly gate Laravel Passport's OAuth client management routes, allowing any authenticated user to register OAuth clients with attacker-controlled redirect URIs. Attackers can trick administrators into approving consent screens, then exchange authorization codes for bearer tokens inheriting full admin API permissions lasting up to 40 years.

snipe-it versions before 8.7.0 fail to validate the requestable flag for asset models in the POST /account/request/asset_model/{modelId} endpoint. Authenticated users can bypass administrative restrictions and create checkout requests for non-requestable asset models by submitting requests directly to the endpoint.

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.

Snipe-IT before 8.7.0 fails to properly sanitize markdown image syntax in note fields, allowing authenticated users to read arbitrary server files and issue server-side HTTP requests. Attackers can submit markdown image syntax in checkout acceptance notes that survive HTML escaping, are expanded by CommonMark parser, and resolved by laravel-mail-auto-embed via file_get_contents or curl, exfiltrating sensitive files like .env containing APP_KEY.

Snipe-IT versions <= 8.6.3 (fixed in 8.7.0) do not validate company assignment authorization before persisting user records via the REST API. In Api\UsersController::store() and ::update(), the user record is filled from the request and saved before the requested company_id / company_ids[] values are filtered against the actor's permitted companies (Company::getIdsForCurrentUser()). On installs using Full Multiple Companies Support (FMCS), a non-superuser holding users.create (or users.edit on a target user) can submit company identifiers for companies outside their scope — including a mix of permitted and foreign ids — causing the account row to be committed to the database before authorization is checked. Where null_company_is_floater=1 is set, the post-hoc filter leaves an empty company pivot and the account is persisted as a "floater" with cross-company visibility, allowing creation or relocation of user accounts across tenant boundaries.

Snipe-IT versions <= 8.6.3 (fixed in 8.7.0) do not check the return value of storage write operations in ImageUploadRequest::handleImages(). When a storage write silently fails, the application still deletes the previous image and persists a reference to a new filename that was never written. A mirror problem exists in deleteExistingImage(), where a failed Storage::delete() still nulls the image field, orphaning the file on disk. The condition is not directly attacker-controlled — it occurs when an authenticated user submits an image while the storage backend transiently fails (e.g., S3 network error, filesystem permission issue, quota exhaustion). The result is unrecoverable loss of the prior image and a durable database-disk inconsistency. All models routed through ImageUploadRequest::handleImages are affected (assets, asset models, users, companies, manufacturers, locations, categories, suppliers, departments, and others).

Snipe-IT before version 8.7.0 wipes 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.

In Snipe-IT up to and including version 8.6.3, the report acceptance endpoints are not correctly scoped when Full Multiple Company Support (FMCS) is enabled. An authenticated user with reports.view permission can send acceptance-reminder emails and permanently delete acceptance records from other companies due to missing scope checks.

Snipe-IT before 8.7.0 contains an authorization bypass vulnerability in Livewire components that enforce authorization only at the route level, not within component lifecycle methods. Attackers with a valid authenticated session can replay signed component snapshots to invoke protected methods and escalate privileges.

In Snipe-IT master-branch builds after 8.6.3 (not in any tagged release), the FMCS location-scoping mismatch report export does not apply CSV formula escaping, unlike other exports. An authenticated user can place a spreadsheet formula in text fields that gets executed when the CSV is opened in spreadsheet applications.

Snipe-IT 8.6.3 and earlier contain a race condition in asset checkout paths. Two concurrent checkout requests for the same available asset can both commit, producing duplicate history rows and events, corrupting audit trail and reporting. Requires authenticated session with assets.checkout permission and precise timing. Fixed in 8.7.0.

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.

Snipe-IT through 8.6.3 does not neutralize formula elements in the 'unaccepted assets' acceptance report CSV export. The report is built manually and does not apply League\Csv\EscapeFormula. An authenticated low-privilege user can place a formula in text fields that gets executed when the CSV is opened in spreadsheet applications.

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, allowing deletion requests to report success while files remain on disk. Administrators see success but physical files persist and remain accessible to those with filesystem or backup access.

Snipe-IT 8.6.3 and earlier do not check the return value of Storage::put() when writing signature and acceptance PDF files. On silent write failures, execution continues and marks acceptance as complete even though evidence files were never stored, yielding incomplete compliance artifacts. Fixed in 8.7.0.

Snipe-IT before 8.7.0 has 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 using @import and url() 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 SQL from an uploaded backup archive directly into the MySQL/MariaDB client without --binary-mode, so lines starting with backslash commands are interpreted as local shell commands. An authenticated superadministrator uploading a crafted ZIP and triggering restore without the clean parameter (not applied by default) can execute arbitrary OS commands as the web app user, exposing secrets and allowing modification of files and data. Version 8.7.0 adds --binary-mode.

Snipe-IT before version 8.6.3 contains an authorization bypass vulnerability in the bulk delete functionality that allows restricted users to soft-delete users outside their authorized scope.

Snipe-IT before version 8.6.2 contains 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.

Snipe-IT before 8.7.0 incorrectly gates the bulk asset restore endpoint on the assets.edit permission instead of assets.delete, allowing users without delete rights to restore soft-deleted assets. Attackers with edit permissions can post asset identifiers to the bulk restore endpoint to undo administrator deletions and bypass intended permission separation.

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.