Katalog podatności CVE

W systemie FOSSBilling w wersjach od 0.5.6 do 0.7.2 istnieje podatność polegająca na tym, że przy wielokrotnym żądaniu resetowania hasła przez tego samego klienta, nie jest generowany nowy token, a wykorzystywany jest istniejący, ważny przez 15 minut od pierwotnego żądania. Atakujący, który przechwycił pierwszy link resetujący, może go użyć nawet po tym, jak ofiara zażąda nowego resetu, ponieważ oryginalny token nie jest unieważniany.

FOSSBilling przed wersją 0.8.0 zawiera podatność, która pozwala pracownikowi z niskimi uprawnieniami na eskalację swoich uprawnień poprzez API administracyjne. Użytkownik z uprawnieniem `staff.create_and_edit_staff` może wywołać endpoint `/api/admin/staff/permissions_update` dla własnego konta i ustawić dowolne uprawnienia, omijając kontrolę dostępu opartą na rolach.

FOSSBilling w wersjach 0.5.3 do 0.7.2 umożliwia uwierzytelnionym klientom odczyt i resetowanie kluczy API dla zamówień, które nie są już aktywne (np. zawieszone, anulowane). Brakuje walidacji stanu zamówienia w dwóch punktach końcowych API klienta, mimo że istnieje pomocnicza funkcja `isActive()` w module `Serviceapikey`, a interfejs użytkownika poprawnie blokuje dostęp dla nieaktywnych zamówień.

FOSSBilling w wersjach przed 0.8.0 umożliwia kontom personelu o niskich uprawnieniach wykonywanie nieautoryzowanych działań poprzez punkty końcowe API administratora. Problem wynika z połączenia flagi modułu `can_always_access` (przyznającej dostęp wszystkim pracownikom) oraz niewystarczających kontroli uprawnień lub niebezpiecznego przetwarzania parametrów na poszczególnych punktach końcowych.

FOSSBilling w wersjach od 0.6.10 do 0.7.2 zawiera podatność na wstrzykiwanie kodu PHP w metodzie Config::prettyPrintArrayToPHP(). Atakujący z uprawnieniami administratora może wstrzyknąć dowolny kod PHP do pliku config.php, który jest wykonywany przy każdym żądaniu HTTP.

W systemie FOSSBilling przed wersją 0.8.0 zawieszanie lub dezaktywacja konta nie unieważnia istniejących sesji uwierzytelnionych. Mechanizm ładowania sesji nie sprawdza statusu konta, co pozwala zawieszonemu użytkownikowi zachować pełny dostęp do wygaśnięcia sesji.

W Coolify od wersji 4.0.0-beta.471 do 4.0.0-beta.473 wystąpił regres w wzorcu SHELL_SAFE_COMMAND_PATTERN, który pozwalał na użycie znaku ampersand (&) w polach poleceń Docker Compose. Umożliwiło to uwierzytelnionemu członkowi zespołu wstrzyknięcie poleceń powłoki wykonywanych na hoście.

Coolify przed wersją 4.0.0-beta.474 zawiera podatność na wstrzykiwanie poleceń w kontenerze bazy danych PostgreSQL. Atakujący z uwierzytelnieniem może wykorzystać kontrolowane przez siebie ustawienia bazy danych (postgres_user i postgres_db) do wstrzyknięcia dowolnych poleceń podczas generowania polecenia healthcheck.

W bibliotece mrubyc do wersji 3.4.1 wykryto błąd polegający na dereferencji wskaźnika NULL w funkcji op_super() w pliku src/vm.c. Problem wynika z braku sprawdzenia w czasie wykonania dla wywołania super na najwyższym poziomie.

W Coolify przed wersją 4.0.0-beta.471 wykryto podatność na wstrzykiwanie poleceń w komponencie GetLogs Livewire. Użytkownik z rolą członka zespołu (najniższe uprawnienia) może wykonać dowolne polecenia jako root na zarządzanych serwerach.

W Coolify przed wersją 4.0.0-beta.471, funkcja LocalFileVolume::saveStorageOnServer tworzy polecenia powłoki z niesanitowanych ścieżek fs_path i parent_dir przed walidacją, a submitFileStorage nie sprawdza ścieżki montowania pliku przed utworzeniem woluminu. Umożliwia to uwierzytelnionemu użytkownikowi dodającemu magazyn plików wykonanie poleceń podczas zapisywania magazynu.

Leantime zawiera podatność CSRF w logowaniu OIDC w metodzie verifyState(), która zawsze zwraca true bez walidacji parametrów stanu. Atakujący może skonstruować złośliwy URL callback z własnym kodem autoryzacyjnym, aby przeprowadzić fiksację sesji i zalogować ofiarę jako atakujący.

Podatność w metodzie Users::getUser API JSON-RPC w Leantime umożliwia uwierzytelnionym użytkownikom pobieranie pełnych rekordów użytkowników, w tym skrótów haseł, sekretów TOTP i tokenów sesji. Brak odpowiednich kontroli autoryzacji pozwala na wyliczenie wszystkich kont i uzyskanie danych uwierzytelniających.

Crawl4AI przed wersją 0.9.0 zawiera podatność SSRF w ścieżce strumieniowej API Dockera. Niezautoryzowany zdalny klient może wysłać żądanie POST do /crawl/stream lub /crawl z parametrem stream=true, wskazując URL na adres wewnętrzny, prywatny lub link-local, a serwer pobierze i przekaże odpowiedź.

Podatność w mechanizmie uwierzytelniania żądań strumieni wideo w Genetec Security Center 5.14.0.0 przed build 5.14.178.18 może umożliwić nieuwierzytelnionemu atakującemu dostęp do strumieni wideo na żywo.

Podatność w silniku wnioskowania vLLM przed wersją 0.24.0 pozwala atakującemu na wykonanie ataku DoS poprzez przesłanie złośliwego wyrażenia regularnego do parametru structured_outputs.regex. Wyrażenie to, pozbawione limitu czasu kompilacji i analizy złożoności, powoduje eksplozję stanów w kompilatorze gramatyki, co prowadzi do zawieszenia procesu wnioskowania.

Traefik w wersjach od 3.7.0 do 3.7.5 ma podatność w dostawcy Kubernetes Gateway API, gdzie dwa zaakceptowane HTTPRoute wskazujące na ten sam backend Service:port, ale z różnymi filtrami backendRef, mogą powodować zastosowanie tylko jednego zestawu filtrów do wszystkich żądań kierowanych do tego backendu. W rezultacie atakujący może narzucić swój kontekst filtru na żądania innej trasy, potencjalnie przekraczając granice przestrzeni nazw.

W silniku vLLM przed wersją 0.24.0 wykryto podatność polegającą na tym, że specjalnie spreparowane żądanie spekulatywnego dekodowania może spowodować wygenerowanie tokena spoza słownika modelu. Prowadzi to do awarii procesu roboczego (worker) z powodu asercji na GPU, co skutkuje przerwaniem wszystkich współbieżnych żądań.

W FOSSBilling przed wersją 0.8.0 brakuje autoryzacji w endpointcie Guest API invoice/update, co pozwala nieuwierzytelnionemu użytkownikowi ze znajomością hasha faktury na zmianę bramki płatności dla niezapłaconej faktury. Atakujący może wykorzystać wyciek hasha (np. przez udostępnione URL-e, nagłówki referrer lub linki e-mail) i zmienić `gateway_id` na dowolną skonfigurowaną w systemie bramkę.

Podatność powoduje uszkodzenie pamięci podczas przetwarzania asynchronicznych parametrów wejściowych z powodu nieprawidłowego obsługiwania zmodyfikowanych wartości między sprawdzeniem a użyciem.