https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Fri, 02 Oct 2026 15:27:56 +0000 https://cve.radiocsirt.org/vuln/euvd-2026-372621 EUVD-2026-372621 https://cve.radiocsirt.org/vuln/euvd-2026-372621 https://cve.radiocsirt.org/vuln/fkie_cve-2026-86749 <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>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://cve.radiocsirt.org/vuln/fkie_cve-2026-86749 https://cve.radiocsirt.org/vuln/ghsa-55vq-5fhf-8c84 <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>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://cve.radiocsirt.org/vuln/ghsa-55vq-5fhf-8c84 https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2981 <p>Ein Angreifer kann mehrere Schwachstellen in Snipe-IT ausnutzen, um beliebigen Code auszuführen, erweiterte Berechtigungen zu erlangen, Sicherheitsmaßnahmen zu umgehen, Cross-Site-Scripting-Angriffe zu starten, sensible Informationen offenzulegen, Daten zu manipulieren, Konten zu übernehmen oder Denial-of-Service-Zustände herbeizuführen.</p> <p>Ein Angreifer kann mehrere Schwachstellen in Snipe-IT ausnutzen, um beliebigen Code auszuführen, erweiterte Berechtigungen zu erlangen, Sicherheitsmaßnahmen zu umgehen, Cross-Site-Scripting-Angriffe zu starten, sensible Informationen offenzulegen, Daten zu manipulieren, Konten zu übernehmen oder Denial-of-Service-Zustände herbeizuführen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2981