CVE-2026-62368

Ścieżka realizacji predefiniowanych zestawów (kit checkout) w Snipe-IT nie egzekwuje izolacji dzierżawców Full Multiple Company Support (FMCS) na celu realizacji. W przeciwieństwie do innych ścieżek realizacji, App\Services\PredefinedKitCheckoutService nigdy nie wywołuje $item->canCheckoutTo($target); wykonuje jedynie sprawdzenie polityki aktor-vs-element oraz sprawdzenie dostępności przed zapisaniem realizacji. Przy włączonym FMCS użytkownik niebędący superużytkownikiem, należący do co najmniej dwóch firm i posiadający uprawnienie assets.checkout, może wysłać żądanie POST do /kits/{kit}/checkout z user_id należącym tylko do firmy B i przypisać temu użytkownikowi zasób firmy A (podobnie licencje, materiały eksploatacyjne i akcesoria zestawu), omijając sprawdzenie niezgodności firm. Problem naprawiono w Snipe-IT 8.7.2.

Snipe-IT przed wersją 8.7.0 pozwala uwierzytelnionemu użytkownikowi z uprawnieniami do zarządzania plikami na przesyłanie załączników XML i XSLT oraz żądanie ich z parametrem inline=true. Przeglądarka może przetworzyć odniesienie xml-stylesheet i wykonać JavaScript wygenerowany przez arkusz stylów w kontekście Snipe-IT. Ofiara musi otworzyć URL załącznika, po czym skrypt może czytać dane samego pochodzenia i wykonywać uwierzytelnione działania z uprawnieniami ofiary.

Snipe-IT przed wersją 8.7.0 pozwala sesji uwierzytelnionej hasłem dla konta z uprawnieniem self.api na dostęp do API tokenów osobistych przed ukończeniem wyzwania drugiego czynnika, ponieważ CheckForTwoFactor jest egzekwowane w grupie middleware web, ale nie w grupie API. Token może czytać i modyfikować zasoby z uprawnieniami ofiary, a dla administratora może dotrzeć do punktu końcowego users/two_factor_reset, co umożliwia przejęcie konta administratora.

Snipe-IT przed wersją 8.7.0 zawiera podatność polegającą na uszkodzonej kontroli dostępu w AssetModelPolicy, gdzie metoda files() kaskaduje z uprawnienia assets.files, umożliwiając uwierzytelnionym użytkownikom przesyłanie i usuwanie załączników w rekordach Asset Model bez wymaganego uprawnienia models.files. Atakujący posiadający tylko uprawnienie assets.files mogą modyfikować współdzielone załączniki modeli ponad granicami firm i ominąć dedykowane uprawnienie models.files, które ma ograniczać zarządzanie plikami we wspólnym katalogu Asset Model.

Snipe-IT do wersji 8.6.3 nie przeprowadza autoryzacji na poziomie obiektu w endpointach updateLicense, updateConsumable, updateAccessory i updateModel oraz w endpointcie storeModel dla Predefined Kits. Istniejąca kontrola autoryzuje tylko nadrzędny Predefined Kit (aktualizacja PredefinedKit), a nie dołączany obiekt podrzędny. W rezultacie uwierzytelniony użytkownik posiadający tylko uprawnienie kits.edit może dołączyć Licencję, Materiał eksploatacyjny, Akcesorium lub Model zasobu, których odczyt jest mu zabroniony (HTTP 403), do Predefined Kit, a indeks relacji zestawu ujawnia nazwę dołączonego obiektu temu użytkownikowi z niskimi uprawnieniami. Jest to odpowiednik ścieżki aktualizacji i storeModel dla CVE-2026-55478, który naprawił tylko metody storeLicense, storeConsumable i storeAccessory w wersji 8.6.2. Należy zauważyć, że updateModel był podatny w kodzie w wersji 8.6.3, ale nieosiągalny w praktyce z powodu literówki w nazwie trasy, która wiązała trasę z nieistniejącą metodą kontrolera, powodując odpowiedzi HTTP 500. Problem został naprawiony w Snipe-IT 8.7.0.

Snipe-IT przed wersją 8.7.0 zawiera podatność na trwały atak XSS w metodzie DepartmentPresenter::formattedNameLink(), gdzie nazwy działów są renderowane bez escapowania w gałęzi fallback dla użytkowników bez uprawnienia departments.view. Użytkownicy z uprawnieniem departments.edit mogą wstrzykiwać złośliwe skrypty do nazw działów, które wykonują się w przeglądarkach wszystkich członków działu podczas ładowania strony My Assets.

Snipe-IT przed wersją 8.7.0 nie koduje znaków HTML w polu employee_num w generatorze PDF akceptacji, co pozwala atakującym z uprawnieniami users.edit na wstrzyknięcie tagów img do funkcji writeHTML() TCPDF. Atakujący może utworzyć złośliwą wartość employee_num zawierającą tag img z dowolnym adresem HTTP(S), co powoduje żądania po stronie serwera do wewnętrznych usług, punktów końcowych metadanych chmury lub zewnętrznych celów, gdy ofiara podpisze akceptację zasobu.

Snipe-IT przed wersją 8.7.0 nie sprawdza wielkości liter w nazwach użytkowników podczas uwierzytelniania SAML, co pozwala atakującym na uwierzytelnienie się jako inni użytkownicy poprzez rejestrację kont IdP z wariantami akcentów lub wielkości liter nazw ofiar. Atakujący mogą wykorzystać domyślną kolację bazy danych utf8mb4_unicode_ci, aby ominąć dopasowanie nazw użytkowników i przejąć konta przez ścieżki logowania federacyjnego, w tym SAML, LDAP i OAuth.

Snipe-IT przed wersją 8.7.0 zawiera podatność niewłaściwego zarządzania własnością w punkcie końcowym API wydawania materiałów eksploatacyjnych, gdzie w kolumnie created_by zapisywane jest id docelowego użytkownika zamiast id uwierzytelnionego wywołującego. Uwierzytelnieni atakujący z uprawnieniem consumables.checkout mogą przeprowadzać wydania, które powodują błędne wpisy w dzienniku audytu w tabeli przestawnej consumables_users, zaciemniając, który operator wykonał akcję.

Snipe-IT przed wersją 8.7.0 nie weryfikuje stanu miękkiego usunięcia w punktach końcowych API wydawania, co pozwala uwierzytelnionym użytkownikom z uprawnieniami do wydawania na przypisywanie aktywnego inwentarza do usuniętych (trashed) celów. Atakujący mogą wysyłać żądania POST do punktów końcowych wydawania sprzętu, komponentów lub materiałów eksploatacyjnych z identyfikatorami usuniętych użytkowników, aktywów lub lokalizacji, tworząc osierocone odniesienia, które uszkadzają księgę aktywów i dzienniki audytu.