https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Mon, 05 Oct 2026 20:58:38 +0000 https://vulnerability.circl.lu/vuln/cve-2026-86749 <p><strong>Affected:</strong> grokability snipe-it</p> <p>Snipe-IT versions &lt;= 8.6.3 (fixed in 8.7.0) do not check the return value of storage write operations in ImageUploadRequest::handleImages(). Because Laravel&#39;s default disk mode does not throw on failure, a silently failed Storage::disk(&#39;public&#39;)-&gt;put(...) call still caused the application to delete the previous image via deleteExistingImage() and to reassign and persist the model&#39;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&#39;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.</p> <p><strong>Affected:</strong> grokability snipe-it</p> <p>Snipe-IT versions &lt;= 8.6.3 (fixed in 8.7.0) do not check the return value of storage write operations in ImageUploadRequest::handleImages(). Because Laravel&#39;s default disk mode does not throw on failure, a silently failed Storage::disk(&#39;public&#39;)-&gt;put(...) call still caused the application to delete the previous image via deleteExistingImage() and to reassign and persist the model&#39;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&#39;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.</p> https://vulnerability.circl.lu/vuln/cve-2026-86749