Katalog podatności CVE

Dell SCG 5.0 Appliance przed wersją 5.36.00.16 oraz Dell SCG 5.0 Application przed wersją 5.36.00.00 zawierają podatność na wstrzykiwanie poleceń systemu operacyjnego (OS Command Injection). Atakujący z niskimi uprawnieniami i dostępem lokalnym może ją wykorzystać, prowadząc do wykonania poleceń.

Dell SCG 5.0 Appliance przed wersją 5.36.00.16 oraz Dell SCG 5.0 Application przed wersją 5.36.00.00 zawierają podatność na wstrzykiwanie poleceń systemu operacyjnego (OS Command Injection). Atakujący z niskimi uprawnieniami i dostępem lokalnym może ją wykorzystać, prowadząc do wykonania poleceń.

Użytkownik może podać wyrażenie, którego długość przekracza limit ParserExpressionSizeLimit() skonfigurowany w środowisku CEL. Alokacja pamięci następuje proporcjonalnie do rozmiaru danych wejściowych, zanim limit zostanie sprawdzony lub wymuszony.

Wtyczka IP2Location Country Blocker dla WordPressa przed wersją 2.45.0 zawiera podatność polegającą na obejściu kontroli dostępu, która pozwala nieuwierzytelnionym zdalnym atakującym ominąć ograniczenia oparte na adresie IP poprzez sfałszowanie nagłówka X-Real-IP. Atakujący mogą ustawić nagłówek X-Real-IP na dozwolony adres IP, aby ominąć ograniczenia dostępu do stron, linków lub całej witryny i uzyskać dostęp do zablokowanych zasobów.

Dell SCG 5.0 Appliance przed wersją 5.36.00.16 oraz Dell SCG 5.0 Application przed wersją 5.36.00.00 zawierają podatność na wstrzykiwanie poleceń (Command Injection). Nieuwierzytelniony atakujący z dostępem zdalnym może ją wykorzystać, prowadząc do wstrzyknięcia skryptu.

Dell SCG 5.0 Appliance przed wersją 5.36.00.16 oraz Dell SCG 5.0 Application przed wersją 5.36.00.00 zawierają podatność na wstrzykiwanie poleceń systemu operacyjnego (OS Command Injection). Atakujący z niskimi uprawnieniami i dostępem lokalnym może ją wykorzystać, prowadząc do wykonania poleceń.

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 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 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 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.