CVE-2026-86772

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 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 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 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.