EUVD-2026-74926
GHSA-55vq-5fhf-8c84
Severity by source
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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
AC:H because triggering requires coincident storage failure outside attacker control; PR:L for authenticated user; I:H for permanent data destruction; A:L for broken image references.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
Lifecycle Timeline
5DescriptionCVE.org
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.
AnalysisAI
Permanent image data destruction in Snipe-IT ≤8.6.3 results from unchecked return values on Laravel storage operations in ImageUploadRequest::handleImages(). When any authenticated user submits an image upload while the configured storage backend (S3, local filesystem, NFS) experiences a transient failure, the silently-returned false from Storage::put() is ignored - the prior image is deleted, and the database record is updated to reference a file that was never written. …
Unlock full vulnerability intelligence
- Risk assessment & exploitation conditions
- Attack chain visualization
- Remediation with exact patch versions
- Threat intelligence from 22 sources
- Personal watchlist & email alerts
Free forever · No credit card required
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata
Vulnerability AssessmentAI
| Exploitation | Exploitation requires: (1) a user authenticated to Snipe-IT with permissions to upload images for any image-carrying model (assets, users, companies, etc. … Additional conditions and limiting factors are described in the full assessment. |
| Risk Assessment | The provided CVSS 4.0 base score of 7.0 (AV:N/AC:L/AT:N/PR:L/UI:P/VC:N/VI:H/VA:L) reflects network accessibility and high integrity impact, which is consistent with the data-destruction outcome. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in. |
| Exploit Scenario | Full exploit scenario with step-by-step reproduction available after sign-in. |
| Remediation | Upgrade to Snipe-IT 8.7.0 or later, which corrects the unchecked return values in ImageUploadRequest::handleImages() and deleteExistingImage() so that storage write and delete failures are detected before destructive follow-on operations execute. … Detailed patch versions, workarounds, and compensating controls in full report. |
Recommended ActionAI
Within 24 hours, audit your Snipe-IT installation to confirm the current version and identify whether you are running version 8.6.3 or earlier-this information is typically visible in Settings or the administrative dashboard. …
Sign in for detailed remediation steps and compensating controls.
Threat intelligence, references, and detailed analysis are available after sign-in.
Cross-Site Request Forgery (CSRF) in GitHub repository snipe/snipe-it prior to v.6.2.3. Rated high severity (CVSS 8.8),
In Snipe-IT, versions v3.0-alpha to v5.3.7 are vulnerable to Host Header Injection. Rated high severity (CVSS 8.8), this
snipe-it is vulnerable to Cross-Site Request Forgery (CSRF). Rated high severity (CVSS 8.8), this vulnerability is remot
snipe-it is vulnerable to Cross-Site Request Forgery (CSRF). Rated high severity (CVSS 8.8), this vulnerability is remot
Session Fixation in GitHub repository snipe/snipe-it prior to 6.0.10. Rated high severity (CVSS 8.0), this vulnerability
Old sessions are not blocked by the login enable function. Rated high severity (CVSS 7.4), this vulnerability is remotel
snipe-it is vulnerable to Server-Side Request Forgery (SSRF). Rated high severity (CVSS 7.2), this vulnerability is remo
Privilege escalation via authorization bypass in Snipe-IT versions prior to 8.6.0 allows any authenticated user holding
Snipe-IT before 7.0.10 allows remote code execution (associated with cookie serialization) when an attacker knows the AP
Missing Authorization in GitHub repository snipe/snipe-it prior to 5.4.4. Rated medium severity (CVSS 6.5), this vulnera
snipe-it is vulnerable to Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'). Rated me
snipe-it is vulnerable to Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'). Rated me
Same weakness CWE-252 – Unchecked Return Value
View allShare
External POC / Exploit Code
Leaving vuln.today