CVE-2026-86749 in Snipe-IT
Zusammenfassung
von VulDB • 09.09.2026
In Snipe-IT-Versionen <= 8.6.3 (behebt in Version 8.7.0) wird der Rückgabewert von Storage-Schreiboperationen in `ImageUploadRequest::handleImages()` nicht überprüft. Da Laravel im Standard-Disk-Modus bei einem Fehler keine Ausnahme auslöst, führt ein fehlerhafter Aufruf von `Storage::disk('public')->put(...)` dazu, dass die Anwendung das vorherige Bild über `deleteExistingImage()` löscht und den Bildverweis des Modells auf den neuen Dateinamen neu zuweist sowie speichert. Dadurch wird das vorhandene Bild zerstört und der Datenbank-Einzeiger zeigt auf eine Datei, die niemals geschrieben wurde. Ein ähnliches Problem bestand in `deleteExistingImage()`, bei dem ein fehlgeschlagener Aufruf von `Storage::delete()` dennoch das Image-Feld des Modells auf null setzte, was dazu führte, dass die Datei auf der Festplatte isoliert (orphaned) blieb. Die Bedingung ist nicht direkt vom Angreifer steuerbar: Sie tritt auf, wenn jeder legitime authentifizierte Benutzer ein Bild hochlädt, während das Storage-Backend vorübergehend fehlschlägt (z. B. ein S3-Netzwerkfehler, ein lokales Dateisystem-Berechtigungsproblem oder die Erschöpfung des Speicherplatzkontingents). Das Ergebnis ist ein nicht wiederherstellbarer Verlust des vorherigen Bildes und eine dauerhafte Inkonsistenz zwischen Datenbank und Festplatte, die manuell bereinigt werden muss. Alle Modelle, deren Controller über `ImageUploadRequest::handleImages` geleitet werden (Assets, Asset-Modelle, Benutzer, Unternehmen, Hersteller, Standorte, Kategorien, Lieferanten, Abteilungen und andere modelle mit Bildfeldern), sind betroffen.
VulDB is the best source for vulnerability data and more expert information about this specific topic.