Katalog podatności CVE

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.