CVE-2026-116198

Snipe-IT przed wersją 8.5.0 zawiera podatność powtórzenia asercji SAML, która pozwala atakującym na ponowne użycie przechwyconych asercji poprzez wykorzystanie nieatomowego sprawdzania nonce w obsłudze SAML acs. Atakujący mogą wysłać równoległe żądania POST do /saml/acs z jedną przechwyconą asercją, aby uzyskać wiele uwierzytelnionych sesji ofiary.

Snipe-IT przed wersją 8.6.3 ignoruje wartość zwracaną przez ldap_start_tls() w Ldap::connectToLdap(), co pozwala atakującym w ścieżce sieciowej wymusić jawne powiązania LDAP. Atakujący mogą odpowiedzieć na żądanie StartTLS błędem protokołu, aby przechwycić poświadczenia konta usługi i hasła logowania użytkowników końcowych.

Snipe-IT przed wersją 8.6.3 zawiera obejście uwierzytelniania w GoogleAuthController::handleGoogleCallback, które loguje użytkownika o nazwie zgodnej z adresem e-mail konta Google bez wymuszania flagi aktywacji. Dezaktywowani użytkownicy z nazwami w formie e-mail i aktywnymi tożsamościami Google mogą zalogować się przez Google SSO i odzyskać sesje na pierwotnym poziomie uprawnień, w tym administratora.

Snipe-IT w wersjach przed 8.7.0 zawiera podatność typu server-side request forgery w funkcji testowania webhooków, która pozwala użytkownikom z uprawnieniami super-administratora na sondowanie wewnętrznych adresów sieciowych, w tym zakresów loopback i RFC1918. Atakujący mogą kierować webhooki na wewnętrzne hosty i porty, a następnie porównywać odpowiedzi 4xx i 5xx z Test Webhooks, aby mapować otwarte porty i aktywne hosty.

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

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