CVE-2026-86749
MediumCVSS 6.3Exploitation Probability (EPSS)
Low risk15th percentile - higher than 15% of all known CVEs
Summary
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).
Risk Assessment
The organization may irreversibly lose images and experience durable data inconsistency requiring manual reconciliation. The risk is moderate because it requires a transient storage failure, but the effects are hard to reverse.
Recommendation
Upgrade Snipe-IT to version 8.7.0 or later. Monitor storage backend health (S3, filesystem, quotas) and regularly verify image reference consistency in the database.
Other vulnerabilities in Snipe-IT
See all- CVE-2026-88894Medium
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.
- CVE-2026-63498High
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.
- CVE-2026-63493High
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.
- CVE-2026-62368High
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.
- CVE-2026-86774Medium
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.
- CVE-2026-86773Medium
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.
- CVE-2026-86772Medium
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.
- CVE-2026-86771High
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.
- CVE-2026-86770High
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.
- CVE-2026-86769Medium
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.
Original NVD description (English source)
Snipe-IT versions <= 8.6.3 (fixed in 8.7.0) do not check the return value of storage write operations in ImageUploadRequest::handleImages(). Because Laravel's default disk mode does not throw on failure, a silently failed Storage::disk('public')->put(...) call still caused the application to delete the previous image via deleteExistingImage() and to reassign and persist the model's image reference to the new filename, destroying the existing image and leaving the database row pointing at a file that was never written. A mirror problem existed in deleteExistingImage(), where a failed Storage::delete() still nulled the model's image field, orphaning the file on disk. The condition is not directly attacker-controlled: it is triggered when any legitimate authenticated user submits an image upload while the storage backend transiently fails (for example an S3 network error, a local filesystem permission problem, or quota exhaustion). The result is unrecoverable loss of the prior image and a durable inconsistency between the database and disk that requires manual reconciliation. All models whose controllers route through ImageUploadRequest::handleImages (assets, asset models, users, companies, manufacturers, locations, categories, suppliers, departments, and other image-carrying models) are affected.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS

