CVE-2026-86749: Unchecked Return Value in grokability snipe-it
Affects grokability snipe-itSource CVE Database V5
Not known to be exploited · CVSS 7.0 High · patch available : patch grokability snipe-it soon.
Data as of 10/25/2026, 04:40:14 UTC
- Exploitation
Not in CISA KEV, no exploitation reported
- EPSS
- 0.3% chance of exploitation in 30 days – higher than 26% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- Patch
- Available
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:N/VI:H/VA:L/SC:N/SI:N/SA:NWhat to do
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| grokabilitysnipe-it | Affected
| Fixed in
|
GitHubgrokability/snipe-itpkg:github/grokability/snipe-itOther threats | Affected
| Fixed in– |
Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.
AI-suggested
A fix is available in Snipe-IT version 8.7.0. Users should upgrade to version 8.7.0 or later to resolve this issue. The vendor manages remediation for this cloud-hosted service if applicable. Until upgraded, manual reconciliation of database and storage inconsistencies may be necessary after storage failures.
Description
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.
Impact
This vulnerability can cause permanent loss of existing images and persistent inconsistencies between the database and storage backend. The database may reference image files that were never successfully written, or files may remain orphaned on disk after deletion attempts. The issue is triggered by transient storage failures during legitimate authenticated user image uploads, not by direct attacker control. This can disrupt asset management and related workflows relying on image data integrity.