SEPTEMBER 14, 2026
Live Feed
Back to database
Case File

CVE-2026-88894

MEDIUM · CVSS 5.4 EPSS 0.23% Public Exploit

Source: NVD + CISA KEV + EPSS · Published 2026-09-10 · Last synced 2026-09-14

CyberRota Analysis

AI-Generated

The vulnerability affects Snipe-IT's predefined kit checkout path, which fails to enforce tenant isolation for users with access to multiple companies, allowing them to checkout assets from one company while using a user ID from another. This could lead to unauthorized access and asset mismanagement, particularly for non-superusers with the assets.checkout permission. Organizations using Snipe-IT with Full Multiple Company Support enabled should prioritize this issue, especially those on versions prior to 8.7.2, to mitigate potential risks of asset misallocation and compliance violations.

Public Exploit Signal

A public exploit, PoC, GitHub repository or Metasploit reference was detected for this CVE.

GitHub PoC Links

Note: these links are listed for security research and verification purposes only.

CVE
CVE-2026-88894
Severity
MEDIUM
CVSS
5.4
EPSS
0.23%

Original NVD Description

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.