Snipe-IT versions prior to 8.5.0 contain a vulnerability in the SAML assertion handling process that allows attackers to replay captured assertions. This flaw arises from a non-atomic nonce check in the SAML ACS handler, enabling attackers to send concurrent POST requests with the same assertion and create multiple authenticated sessions without triggering identity provider revocation.
Snipe-IT before 8.6.3 ignores the ldap_start_tls() return value in Ldap::connectToLdap(), allowing on-path attackers to force cleartext LDAP binds. Attackers can answer the StartTLS request with a protocol error to capture service-account credentials and end-user login passwords.
CVE-2026-116199 is a critical authentication bypass vulnerability in Snipe-IT versions before 8.6.3. It occurs in the GoogleAuthController::handleGoogleCallback method, where the system logs in users based solely on matching their username to the Google account email without verifying if the user is activated. This flaw allows deactivated users with email-shaped usernames and valid Google identities to regain access via Google SSO, restoring their original permission levels, including administrative privileges.
Snipe-IT versions before 8.7.0 have a vulnerability where sensitive custom-field data can be stored in plaintext instead of being encrypted. This occurs in the Api\AssetsController::store method when authenticated API users lacking the assets.view.encrypted_custom_fields permission create assets. As a result, sensitive data intended to be encrypted is exposed in the database, backups, or replicas.
Snipe-IT versions before 8.7.0 have a server-side request forgery (SSRF) vulnerability in the webhook testing feature. This flaw allows super-admin users to send requests to internal network addresses, including loopback and private IP ranges. By analyzing the difference in HTTP response codes (4xx vs 5xx) from the Test Webhooks function, attackers can map internal hosts and open ports. The vulnerability is fixed in version 8.7.0.
Snipe-IT is an IT asset/license management system. Prior to 8.7.0, a user with the customfields.create permission can store markup in CustomField.name, and app/Presenters/AssetPresenter.php assigns that value as an unescaped bootstrap-table header title. When another user opens an asset-list page associated with the fieldset, the stored markup executes on page load in that user's Snipe-IT session. This can expose same-origin data and perform authenticated actions with the victim's privileges, including privilege escalation when a superuser views the affected list. This issue is fixed in version 8.7.0.
Snipe-IT is an IT asset/license management system. Prior to 8.7.0, a password-authenticated session for an account with self.api permission can 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 advisory states that the resulting persistent API token can read and modify resources with the victim's permissions and, for an administrator, can reach the users/two_factor_reset endpoint. Resetting the administrator's enrolled second factor allows the password-holding attacker to enroll an attacker-controlled factor, take over the administrator's web account, and lock out the legitimate user. The token does not create a web session, but it provides broad API access while the same browser session remains blocked at the two-factor page. This vulnerability is fixed in 8.7.0.
Snipe-IT is an IT asset/license management system. Prior to 8.7.0, the uploaded-files API endpoint GET /api/v1/{object_type}/{id}/files/{file_id} allows an authenticated user with file-management access to upload XML and XSLT attachments and request them with the inline=true parameter. The app/Http/Controllers/Api/UploadedFilesController.php show() path does not apply the safe-inline allowlist used by the equivalent web controller, so the browser can process an attacker-controlled xml-stylesheet reference and execute JavaScript generated by the stylesheet in the Snipe-IT origin. A victim who is authorized to view the object must open the attachment URL, after which the script can read same-origin data and perform authenticated actions with the victim's privileges. This issue is fixed in version 8.7.0.
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 that blocks the same operation on every other checkout path. The issue is fixed in Snipe-IT 8.7.2; it was runtime-verified on v8.6.3 and code-inspected on v8.7.1, and the affected service has lacked the check since 2019, so earlier FMCS deployments are likely also affected.
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 versions 8.6.3 up to but not including 8.7.0 contain a stored cross-site scripting (XSS) vulnerability in the DepartmentPresenter::formattedNameLink() function. This flaw allows users with departments.edit permission to inject malicious scripts into department names, which then execute in the browsers of department members when they view their My Assets page. The vulnerability arises because department names are rendered unescaped for users without departments.view permission. The CVSS 4.0 score is 5.1, indicating a medium severity issue.
Snipe-IT versions before 8.7.0 fail 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 versions before 8.7.0 contain 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 have a vulnerability where company scope filtering is not applied on the GET /hardware/requested endpoint when Full Multiple Company Support is enabled. This allows authenticated users with assets.view permission to access pending asset requests from all companies, exposing sensitive information such as asset names, requester details, locations, and expected check-in dates.
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.