CVE-2026-86749 in Snipe-IT
Riassunto
di VulDB • 09/09/2026
Le versioni di Snipe-IT <= 8.6.3 (corrette nella versione 8.7.0) non verificano il valore restituito delle operazioni di scrittura su storage in ImageUploadRequest::handleImages(). Poiché la modalità predefinita del disco di Laravel non genera eccezioni in caso di errore, una chiamata a Storage::disk('public')->put(...) fallita silenziosamente causava comunque l'eliminazione dell'immagine precedente tramite deleteExistingImage() e il riassegnamento e la persistenza del riferimento all'immagine del modello al nuovo nome file, distruggendo l'immagine esistente e lasciando la riga del database puntare a un file che non è mai stato scritto. Un problema analogo era presente in deleteExistingImage(), dove una chiamata fallita a Storage::delete() impostava comunque a null il campo immagine del modello, rendendo orfano il file sul disco. La condizione non è direttamente controllabile dall'attaccante: viene attivata quando qualsiasi utente autenticato legittimo carica un'immagine mentre lo storage backend subisce un guasto transitorio (ad esempio un errore di rete S3, un problema di permessi del filesystem locale o l'esaurimento della quota). Il risultato è una perdita irreversibile dell'immagine precedente e una persistente inconsistenza tra il database e il disco che richiede una riconciliazione manuale. Tutti i modelli i cui controller passano attraverso ImageUploadRequest::handleImages (assets, asset models, users, companies, manufacturers, locations, categories, suppliers, departments e altri modelli contenenti immagini) sono interessati.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.