Podatności Snipe-IT

Ś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 pozwala użytkownikowi z uprawnieniem customfields.create na przechowywanie znaczników w CustomField.name, które są przypisywane jako nieucieczkowy tytuł nagłówka bootstrap-table. Gdy inny użytkownik otworzy stronę listy zasobów, przechowywane znaczniki wykonują się na stronie w sesji ofiary, co może ujawnić dane samego pochodzenia i wykonać uwierzytelnione działania, w tym eskalację uprawnień.

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.

Snipe-IT przed wersją 8.7.0 nie stosuje filtrowania zakresu firm do punktu końcowego GET /hardware/requested, gdy włączona jest pełna obsługa wielu firm, co pozwala uwierzytelnionym użytkownikom z uprawnieniem assets.view na odczyt oczekujących żądań aktywów ze wszystkich firm. Atakujący mogą pobierać dane między dzierżawcami, w tym nazwy żądanych aktywów, nazwy wyświetlane osób żądających, linki do profili, lokalizacje i oczekiwane daty zwrotu, bez manipulacji parametrami.

Snipe-IT do wersji 8.6.3 włącznie zawiera warunek wyścigu (TOCTOU) w punkcie końcowym API wydawania materiałów eksploatacyjnych (POST /api/v1/consumables/{consumable_id}/checkout). Żądana ilość jest weryfikowana względem liczby pozostałych jednostek przed rozpoczęciem transakcji bazy danych, a transakcja tworzy rekordy wydania bez blokowania wiersza materiału ani ponownego sprawdzania dostępności. Uwierzytelniony użytkownik z uprawnieniem do wydawania materiałów może wysyłać równoczesne żądania wydania dla tego samego materiału, tak że oba żądania przechodzą kontrolę dostępności i kończą się sukcesem, nadprzydzielając stan magazynowy i doprowadzając do ujemnego stanu (np. materiał z 1 pozostałą jednostką kończy na -1 po dwóch równoczesnych wydaniach po 1 jednostce). Problem naprawiono w wersji 8.7.0, która ponownie pobiera wiersz nadrzędny z lockForUpdate wewnątrz transakcji i ponownie weryfikuje dostępność.

Snipe-IT przed wersją 8.7.0 nie egzekwuje autoryzacji wydania, gdy pola przypisania są przesyłane do punktu końcowego aktualizacji aktywa. Uwierzytelnieni użytkownicy z uprawnieniem do edycji, ale jawnie pozbawieni uprawnienia do wydania, mogą ponownie przypisywać aktywa, omijać procedury przyjęcia i zmieniać rekordy opieki, przesyłając parametry assigned_user, assigned_asset lub assigned_location do PATCH /api/v1/hardware/{id}.

Snipe-IT do wersji 8.6.4 (naprawione w 8.7.0) nie egzekwuje uprawnienia components.view na uwierzytelnionym punkcie końcowym GET /api/v1/hardware/<asset-id>/assigned/components. Punkt końcowy autoryzuje tylko assets.view na nadrzędnym zasobie przed zwróceniem powiązanych szczegółów komponentów; sprawdzenie components.view jest stosowane tylko do flagi available_actions.view w odpowiedzi, a nie do zwracanych danych. W rezultacie uwierzytelniony użytkownik posiadający tylko assets.view może wyliczyć identyfikatory komponentów, nazwy, przypisane ilości i notatki, które są w inny sposób chronione — bezpośredni punkt końcowy GET /api/v1/components/<id> poprawnie zwraca 403 Forbidden dla takich użytkowników.

Snipe-IT w wersjach od 7.0.12 do 8.6.3 zawiera podatność na obejście autoryzacji w komponencie Livewire importer. Uwierzytelniony użytkownik niebędący superuserem, posiadający uprawnienie importu, może przeglądać wszystkie rekordy importu (nazwy plików, ścieżki, rozmiary, typy, znaczniki czasu) oraz ładować dane podglądu innych użytkowników, w tym nagłówki kolumn i pierwsze wiersze CSV, co może ujawniać dane osobowe, numery seryjne i klucze licencyjne. Wpływ ograniczony do danych podglądu, nie całego pliku CSV; superuserzy nie są dotknięci. Naprawiono w wersji 8.7.0.

Snipe-IT przed wersją 8.7.0 nie stosuje middleware CheckUserIsActivated do grupy middleware 'api' w app/Http/Kernel.php, a dezaktywacja użytkownika nie unieważnia jego osobistych tokenów dostępu Passport. W rezultacie, mimo że dezaktywowane konto jest poprawnie odrzucane przy logowaniu przez web, jego istniejący token API nadal się uwierzytelnia i przyznaje dostęp do odczytu i zapisu do REST API (zasoby, użytkownicy, licencje itp.) na dotychczasowym poziomie uprawnień, aż do wygaśnięcia tokena. Dezaktywowane konto z uprawnieniami do zarządzania użytkownikami może samo się reaktywować przez API, trwale niwecząc kontrolę dezaktywacji.

snipe-it przed wersją 8.7.0 zawiera podatność na obejście autoryzacji w punktach końcowych drukowania lokalizacji, która nie egzekwuje kontroli autoryzacji per model. Uwierzytelnieni atakujący z uprawnieniem do przeglądania lokalizacji mogą uzyskać dostęp do punktów końcowych printassigned i printallassigned, aby pobrać powiązanych użytkowników, zasoby, akcesoria, materiały eksploatacyjne i komponenty, niezależnie od ich indywidualnych uprawnień do modeli.

Snipe-IT w wersjach 8.2.0 do 8.6.x (naprawione w 8.7.0) zawiera wadę nieprawidłowej autoryzacji w app/Http/Controllers/Users/UsersController::update(). Trasa edycji pojedynczego użytkownika przypisywała pole activated z danych żądania przed oceną bramki autoryzacji canEditAuthFields, więc uwierzytelniony nie-administrator z uprawnieniem users.edit w zakresie firmy docelowej może wysłać pełne poprawne żądanie PUT do /users/{id} i przełączyć flagę activated na dowolnym użytkowniku, w tym na kontach administratora i superużytkownika. Dezaktywacja administratora blokuje to konto w aplikacji, dopóki inny administrator lub superużytkownik go nie ponownie włączy. Tylko pole activated jest dotknięte; nazwa użytkownika, e-mail, hasło i uprawnienia pozostają chronione przez bramkę, żadne dane nie są ujawniane, a API (Api\UsersController::update) i ścieżki edycji zbiorczej nie są dotknięte.

Snipe-IT przed wersją 8.7.0 nie autoryzuje punktu końcowego POST /hardware/history, co pozwala każdemu uwierzytelnionemu użytkownikowi na ponowne przypisanie dowolnych zasobów i modyfikację dzienników audytu. Atakujący mogą przesłać plik CSV, aby przypisać zasoby między firmami i wstrzykiwać fałszywe wpisy do dziennika audytu, naruszając integralność inwentarza i odpowiedzialność.

Snipe-IT przed wersją 8.7.0 nie egzekwuje prawidłowo bramki autoryzacji viewKeys w punktach końcowych eksportu CSV i API index, umożliwiając uwierzytelnionym użytkownikom z tylko uprawnieniem licenses.view dostęp do kluczy produktów. Atakujący mogą pobrać wszystkie klucze licencji masowo przez eksport CSV lub zweryfikować potencjalne klucze poprzez różnice w odpowiedziach API, bez potrzeby posiadania uprawnienia viewKeys.

Snipe-IT przed wersją 8.7.0 nie egzekwuje prawidłowo dostępu do zaszyfrowanych wartości pól niestandardowych w szablonach formularzy zasobów dla elementów listbox, textarea, markdown-textarea oraz date/datetime picker. Uwierzytelnieni użytkownicy z uprawnieniami assets.edit, assets.checkin, assets.checkout lub assets.audit mogą odczytać zaszyfrowane wartości pól niestandardowych w postaci jawnej, otwierając formularze zasobów, omijając sprawdzenie uprawnienia assets.view.encrypted_custom_fields.

Snipe-IT 8.5.0 do 8.6.3 zawiera podatność na otwarte przekierowanie w punkcie końcowym SAML assertion-consumer (SamlController::acs, POST /saml/acs). Punkt końcowy zapisywał parametr RelayState POST bezpośrednio do klucza sesji url.intended Laravel z usuniętymi tylko znakami CR/LF, a LoginController później wydawał redirect()->intended(), który przekazuje absolutny URL bez zmian do nagłówka Location. Nieuwierzytelniony atakujący, który nakłoni użytkownika instancji z włączonym SAML-SSO do odwiedzenia spreparowanego linku SSO inicjowanego przez IdP, może spowodować przekierowanie przeglądarki ofiary na dowolny zewnętrzny absolutny URL natychmiast po pomyślnym uwierzytelnieniu, co według porady ułatwia phishing mający na celu kradzież poświadczeń. Nie jest wymagane żadne konto w docelowej instancji ani kompromitacja dostawcy tożsamości. Dotknięte są tylko wdrożenia z włączonym SAML SSO. Naprawione w 8.7.0 (commit d30b73d, PR #19386), które waliduje RelayState przez nową funkcję Helper::sameOriginUrl przed zapisaniem.

Snipe-IT w wersjach 4.2.0 do 8.6.3 udostępnia automatycznie zarejestrowane trasy Laravel Passport dla osobistych tokenów dostępu (GET, POST, DELETE /oauth/personal-access-tokens*) tylko z oprogramowaniem pośredniczącym 'web' i 'auth:web', bez bramki uprawnień self.api, którą Snipe-IT egzekwuje na własnych punktach końcowych tokenów (/account/api i /api/v1/account/personal-access-tokens). Każdy użytkownik z ważną sesją webową i odpowiednim tokenem CSRF może wysłać POST do /oauth/personal-access-tokens i wygenerować długożyjący token bearer dla własnego konta, nawet gdy administrator odmówił uprawnienia self.api. Wydany token nadal podlega istniejącym politykom autoryzacji per punkt końcowy, więc nie jest to eskalacja uprawnień; to niweczy administracyjną kontrolę mającą na celu zablokowanie dostępu API/skryptowego na poziomie uprawnień samego użytkownika. Naprawione w 8.7.0 (commit 3f74b8c), które rejestruje nadrzędne trasy opakowane w oprogramowanie pośredniczące can:self.api.

Snipe-IT przed wersją 8.7.0 nieprawidłowo zabezpiecza trasy zarządzania klientami OAuth Laravel Passport, co pozwala każdemu uwierzytelnionemu użytkownikowi na rejestrację klientów OAuth z kontrolowanymi przez atakującego URI przekierowań. Atakujący mogą nakłonić administratorów do zatwierdzenia ekranów zgody, a następnie wymienić kody autoryzacyjne na tokeny Bearer z pełnymi uprawnieniami API administratora, ważnymi nawet przez 40 lat.

snipe-it przed wersją 8.7.0 nie waliduje flagi requestable dla modeli zasobów w punkcie końcowym POST /account/request/asset_model/{modelId}. Uwierzytelnieni użytkownicy mogą ominąć administracyjne ograniczenia i tworzyć żądania wypożyczenia dla modeli zasobów, które nie są requestable, wysyłając żądania bezpośrednio do punktu końcowego.

snipe-it przed wersją 8.7.0 nie egzekwuje zakresowania FMCS per instancja w punktach końcowych audytu zasobów, polegając wyłącznie na filtrowaniu na poziomie zapytań zamiast na kontrolach autoryzacji na poziomie polityki. Atakujący z ważnymi sesjami i uprawnieniami assets.audit mogli zapisywać wpisy dziennika audytu przeciwko zasobom z innych firm, gdyby zakres na poziomie zapytań został ominięty lub zrefaktorowany.

Snipe-IT przed wersją 8.7.0 nieprawidłowo sanityzuje składnię obrazów Markdown w polach notatek, co pozwala uwierzytelnionym użytkownikom na odczyt dowolnych plików serwera i wysyłanie żądań HTTP po stronie serwera. Atakujący mogą przesłać składnię obrazów Markdown w notatkach akceptacji, która przetrwa kodowanie HTML, jest rozwijana przez parser CommonMark i rozwiązywana przez laravel-mail-auto-embed za pomocą file_get_contents lub curl, co umożliwia eksfiltrację wrażliwych plików, takich jak .env zawierający APP_KEY.

Snipe-IT w wersjach do 8.6.3 (poprawione w 8.7.0) nie weryfikuje autoryzacji przypisania firmy przed zapisaniem rekordów użytkowników przez REST API. W Api\UsersController::store() i ::update() rekord użytkownika jest wypełniany z żądania i zapisywany przed filtrowaniem żądanych wartości company_id / company_ids[] względem firm dozwolonych dla aktora (Company::getIdsForCurrentUser()). W instalacjach z pełnym wsparciem wielu firm (FMCS), nie-superużytkownik z uprawnieniami users.create (lub users.edit na docelowym użytkowniku) może przesłać identyfikatory firm spoza swojego zakresu — w tym mieszankę dozwolonych i obcych identyfikatorów — co powoduje zapisanie wiersza konta w bazie danych przed sprawdzeniem autoryzacji. Gdy ustawione jest null_company_is_floater=1, filtr po fakcie pozostawia pusty pivot firmy, a konto jest zapisywane jako "floater" z widocznością między firmami, co pozwala na tworzenie lub przenoszenie kont użytkowników między granicami dzierżawców.

Snipe-IT w wersjach <= 8.6.3 (naprawione w 8.7.0) nie sprawdza wartości zwracanej operacji zapisu w ImageUploadRequest::handleImages(). Gdy zapis do magazynu nie powiedzie się po cichu, aplikacja i tak usuwa poprzedni obraz i zapisuje w bazie odniesienie do nowej nazwy pliku, który nigdy nie powstał. Analogiczny problem występuje w deleteExistingImage(), gdzie nieudane Storage::delete() zeruje pole obrazu, osierocając plik na dysku. Problem nie jest bezpośrednio kontrolowany przez atakującego — występuje, gdy uwierzytelniony użytkownik wysyła obraz, a backend magazynu chwilowo zawodzi (np. błąd sieci S3, problem z uprawnieniami, wyczerpanie limitu). Skutkuje to nieodwracalną utratą poprzedniego obrazu i trwałą niespójnością między bazą danych a dyskiem. Dotyczy to wszystkich modeli obsługiwanych przez ImageUploadRequest::handleImages (zasoby, modele zasobów, użytkownicy, firmy, producenci, lokalizacje, kategorie, dostawcy, działy i inne).

Snipe-IT przed wersją 8.7.0 czyści bazę danych przed walidacją przesłanego archiwum kopii zapasowej w punkcie końcowym przywracania. Superużytkownicy przesyłający uszkodzone lub nieprawidłowe pliki zip powodują trwałą utratę danych bez możliwości odzyskania lub wycofania zmian.

W Snipe-IT do wersji 8.6.3 włącznie, punkty końcowe raportów akceptacji nie są poprawnie ograniczone, gdy włączona jest pełna obsługa wielu firm (FMCS). Uwierzytelniony użytkownik z uprawnieniem reports.view może wysyłać e-maile z przypomnieniami i trwale usuwać rekordy akceptacji z innych firm, wykorzystując brak odpowiedniego sprawdzania zakresu.

Snipe-IT przed wersją 8.7.0 zawiera podatność na obejście autoryzacji w komponentach Livewire, które egzekwują autoryzację tylko na poziomie trasy, a nie w metodach cyklu życia komponentu. Atakujący z ważną sesją mogą odtwarzać podpisane migawki komponentów, aby wywoływać chronione metody i eskalować uprawnienia.

W wersjach Snipe-IT po 8.6.3 (z gałęzi master, nie wydanych w żadnym tagu) eksport raportu o niezgodnościach zakresu FMCS nie stosuje zabezpieczeń przed formułami CSV, w przeciwieństwie do innych eksportów. Uwierzytelniony użytkownik może umieścić formułę w polach tekstowych, która zostanie wykonana po otwarciu pliku CSV w programach arkuszowych.

Snipe-IT 8.6.3 i wcześniejsze zawierają podatność na wyścig (race condition) w ścieżkach wydawania aktywów. Dwa równoczesne żądania wydania tego samego dostępnego aktywa mogą oba zobaczyć je jako dostępne i oba zostać zatwierdzone, co prowadzi do zduplikowanych wpisów historii, podwojenia licznika i zdarzeń, uszkadzając dziennik audytu i raporty. Wymaga uwierzytelnionej sesji z uprawnieniem assets.checkout i precyzyjnego czasu. Naprawiono w 8.7.0.

Snipe-IT przed wersją 8.7.0 nie ogranicza poprawnie zapytań raportu akceptacji zasobów do firmy, co pozwala uwierzytelnionym użytkownikom z uprawnieniem reports.view na odczyt oczekujących akceptacji we wszystkich firmach. Atakujący mogą uzyskać dostęp do strony raportu lub eksportu CSV, ujawniając szczegóły inwentarza i nazwiska osób przypisanych.

Snipe-IT do wersji 8.6.3 nie neutralizuje elementów formuł w eksporcie CSV raportu akceptacji 'niezaakceptowane zasoby'. Raport jest budowany ręcznie i nie stosuje zabezpieczeń League\Csv\EscapeFormula. Uwierzytelniony użytkownik z niskimi uprawnieniami może umieścić formułę w polach tekstowych, która zostanie wykonana po otwarciu pliku CSV w programach arkuszowych.

Snipe-IT przed wersją 8.7.0 nie sanityzuje pola tekstowego EULA kategorii przed renderowaniem go w wiadomościach e-mail potwierdzających wydanie. Atakujący z niskimi uprawnieniami mogą wstrzyknąć składnię obrazów Markdown lub surowe tagi HTML img wskazujące na lokalne pliki lub zdalne adresy URL, które biblioteka auto-embed w mailach rozwiązuje po stronie serwera i zwraca jako załączniki e-mail, co umożliwia eksfiltrację wrażliwych plików, takich jak dane uwierzytelniające .env, oraz ataki SSRF.

Snipe-IT przed wersją 8.7.0 nie sprawdza wartości zwracanej przez Storage::delete() w kontrolerach UploadedFilesController, co pozwala na zgłaszanie sukcesu usunięcia, podczas gdy pliki pozostają na dysku. Administratorzy usuwający załączniki otrzymują komunikaty o sukcesie, ale pliki fizyczne pozostają dostępne dla osób z dostępem do systemu plików lub kopii zapasowych.

Snipe-IT 8.6.3 i wcześniejsze nie sprawdzają wartości zwracanej przez Storage::put() podczas zapisywania plików podpisu i PDF akceptacji. W przypadku cichych błędów zapisu (np. ograniczone uprawnienia, wygasłe poświadczenia S3, brak miejsca) wykonanie kontynuuje i oznacza akceptację jako zakończoną, mimo że pliki dowodowe nie istnieją. Prowadzi to do niekompletnych artefaktów zgodności. Naprawiono w 8.7.0.

Snipe-IT przed wersją 8.7.0 zawiera podatność na wstrzykiwanie CSS w polu Custom CSS z powodu niepełnej sanityzacji, która odwraca kodowanie HTML dla znaków większości i cudzysłowu. Superużytkownicy mogą umieścić złośliwe ładunki CSS używając @import i url() w celu eksfiltracji tokenów CSRF innych superużytkowników poprzez reguły selektorów atrybutów, co umożliwia przejęcie konta.

Snipe-it przed wersją 8.7.0 nie egzekwuje autoryzacji podglądu zasobu w punkcie końcowym GET /hardware/{asset}/barcode. Uwierzytelnieni atakujący mogą iterować identyfikatory zasobów, aby pobierać kody kreskowe i enumerować tagi zasobów w różnych dzierżawcach, w tym zasoby miękkiego usunięcia i międzyfirmowe.

Snipe-it przed wersją 8.7.0 zawiera podatność na nieprawidłowe obliczenia w obsłudze żądań zamówień, która pozwala uwierzytelnionym użytkownikom na uszkodzenie licznika assets.requests_counter poprzez zduplikowane zgłoszenia i anulowania bez aktywnych żądań. Atakujący mogą wielokrotnie wywoływać punkty anulowania bez aktywnych żądań, aby doprowadzić licznik do wartości ujemnej, lub zgłaszać zduplikowane żądania zamówień, aby zawyżyć licznik, fałszując oczekujące zapotrzebowanie w kolejce administratora.

Snipe-it przed wersją 8.7.0 zawiera podatność na podrabianie żądań po stronie serwera (SSRF) w regule walidacji ExternalUrl, która nie wykrywa adresów przejściowych IPv6 kodujących prywatne cele IPv4. Atakujący z uprawnieniami super-administratora mogą skonfigurować adresy URL webhooków przy użyciu adresów przejściowych NAT64, 6to4 lub Teredo, aby ominąć zabezpieczenia SSRF i uzyskać dostęp do usług wewnętrznych lub punktów końcowych metadanych chmury.

Snipe-IT przed wersją 8.7.1 nie sprawdza długości pola notatki w punkcie końcowym POST /account/accept/{acceptance}, co pozwala uwierzytelnionym użytkownikom na przesyłanie nieograniczonych danych, które trafiają do synchronicznego renderowania CommonMark. Atakujący mogą przesyłać duże wartości notatek, aby wyczerpać CPU procesów PHP i spowodować odmowę usługi poprzez wyczerpanie zasobów w potoku parsowania markdown.

Snipe-IT przed wersją 8.7.0 przesyła wpis SQL z przesłanego archiwum kopii zapasowej bezpośrednio do klienta MySQL/MariaDB bez flagi --binary-mode, więc klient interpretuje linie zaczynające się od komend backslash, takich jak \!, jako lokalne komendy powłoki. Uwierzytelniony superadministrator, który przesyła spreparowany plik ZIP i wywołuje przywracanie bez opcjonalnego parametru czyszczącego (który nie jest domyślnie stosowany), może wykonać dowolne polecenia systemu operacyjnego jako użytkownik aplikacji webowej, ujawniając sekrety aplikacji (w tym dane uwierzytelniające bazy danych i APP_KEY) oraz umożliwiając modyfikację plików i danych. Wersja 8.7.0 dodaje flagę --binary-mode.

Snipe-IT przed wersją 8.6.3 zawiera podatność obejścia autoryzacji w funkcji masowego usuwania, która pozwala ograniczonym użytkownikom na miękkie usuwanie użytkowników spoza ich zakresu uprawnień.

Snipe-IT przed wersją 8.6.2 zawiera podatność obejścia autoryzacji w akcjach raportu akceptacji przy włączonej pełnej obsłudze wielu firm. Uwierzytelnieni użytkownicy z uprawnieniem reports.view mogą wyliczać sekwencyjne ID akceptacji i miękko usuwać lub wysyłać przypomnienia dla akceptacji innych firm.

Snipe-IT przed wersją 8.7.0 błędnie weryfikuje uprawnienia dla punktu końcowego masowego przywracania zasobów, wymagając uprawnienia assets.edit zamiast assets.delete. Użytkownicy bez prawa do usuwania mogą przywracać miękkie usunięte zasoby, co pozwala na cofnięcie usunięć dokonanych przez administratora i obejście separacji uprawnień.

Snipe-IT przed wersją 8.6.2 zawiera podatność XSS (zapisanego) w nazwie producenta lub dostawcy. Specjalnie spreparowana nazwa może wykonać JavaScript w przeglądarce uwierzytelnionego użytkownika podczas przeglądania strony szczegółów producenta lub dostawcy, potencjalnie ujawniając dane lub umożliwiając działania w kontekście sesji.