Skip to main content
CVE-2026-86749VulnerabilityPublished 09/09/2026Updated 09/19/2026

CVE-2026-86749: Unchecked Return Value in grokability snipe-it

Affects grokability snipe-itSource CVE Database V5

0

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

CVSS 4.0 base score
7.0High
How severe the flaw is on the 0–10 CVSS scale.
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:N

What to do

Affected software

ProductAffectedFixed in
grokabilitysnipe-itAffected
  • <8.7.0
Fixed in
  • 8.7.0
GitHubgrokability/snipe-itpkg:github/grokability/snipe-itOther threatsAffected
  • <=8.6.3
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.

References

Community reviews

Loading reviews…