Katalog podatności CVE

Podatność polegająca na przechodzeniu do ścieżek względnych w funkcji przesyłania plików w MicroRealEstate umożliwia potencjalne nadpisywanie plików systemowych przez atakujących. Problem dotyczy wersji do 1.0.0-alpha3 włącznie.

Podatność w MicroRealEstate wynika z uszkodzonych kontroli dostępu na poziomie obiektu oraz użycia deterministycznego wzorca podczas generowania losowych identyfikatorów. Umożliwia to atakującym nieautoryzowany dostęp do dokumentów przesłanych przez wynajmujących lub najemców.

Podatność w MicroRealEstate umożliwia nieautoryzowany dostęp do obiektów poprzez funkcję generowania PDF. Problem dotyczy wersji do 1.0.0-alpha3 włącznie.

Podatność w MicroRealEstate umożliwia atakującym ominięcie uwierzytelniania z powodu braku zarządzania stanem tokenów. Pozwala to na brute-force jednorazowych haseł (OTP) i zalogowanie się jako dowolny użytkownik.

Wtyczka Frontend File Manager dla WordPressa do wersji 23.6 nie waliduje ścieżki pliku pochodzącej z danych użytkownika przed usunięciem wskazanego pliku, co pozwala nieuwierzytelnionym użytkownikom na usunięcie dowolnych plików na serwerze (takich jak wp-config.php), gdy tryb przesyłania plików przez gości jest włączony. Usunięcie pliku wp-config.php zmusza witrynę do uruchomienia procedury instalacyjnej, co może prowadzić do pełnego przejęcia strony.

Coolify przed wersją 4.0.0-beta.469 zawiera podatność polegającą na nieprawidłowym zabezpieczeniu pojedynczych cudzysłowów w funkcji executeInDocker(). Atakujący, którzy mogą edytować ustawienia aplikacji, mogą wstrzyknąć pojedynczy cudzysłów do parametrów docker_compose_custom_build_command lub docker_compose_custom_start_command, co pozwala na wykonanie dowolnych poleceń na hoście zarządzanego serwera podczas wdrożeń, omijając izolację kontenera Docker.

Coolify przed wersją 4.0.0-beta.474 zawiera podatność w skrypcie inicjalizacyjnym PostgreSQL, która pozwala uwierzytelnionemu użytkownikowi na zapis plików poza zamierzonym katalogiem i wykonanie kodu poprzez inicjalizację bazy danych.

Coolify przed wersją 4.0.0-beta.471 zawiera podatność polegającą na braku sanityzacji nazw woluminów kontrolowanych przez użytkownika. Nazwy te są interpolowane do poleceń powłoki wykonywanych na zarządzanych serwerach, co umożliwia uwierzytelnionemu członkowi wstrzyknięcie metaznaków powłoki i wykonanie kodu jako root podczas operacji na woluminach.

W Coolify przed wersją 4.0.0-beta.471, endpoint GET /invitations/{uuid} umożliwia resetowanie hasła ofiary przez atakującego, który zna UUID zaproszenia. Atakujący może nakłonić ofiarę do odwiedzenia spreparowanego URL-a, co skutkuje ustawieniem hasła na przewidywalną wartość.

Coolify przed wersją 4.0.0-beta.471 zawiera podatność na wstrzykiwanie poleceń powłoki. Pole LocalPersistentVolume.name jest interpolowane bezpośrednio do poleceń dockera bez odpowiedniego escapowania argumentów, co pozwala uwierzytelnionemu użytkownikowi na wykonanie dowolnych poleceń na zarządzanych serwerach podczas usuwania zasobu.

W Coolify przed wersją 4.0.0-beta.471, polecenia przed i po wdrożeniu są zabezpieczone przez escapowanie pojedynczego cudzysłowu, ale następnie przesyłane przez SSH heredoc, który zachowuje znaki nowej linii. Umożliwia to uwierzytelnionemu użytkownikowi wstrzyknięcie dodatkowych poleceń powłoki, które wykonują się na zdalnym serwerze podczas wdrożenia.

W Coolify przed wersją 4.0.0-beta.471 komponent Livewire Server\Resources udostępnia publiczne metody (startUnmanaged, stopUnmanaged, restartUnmanaged), które przyjmują identyfikator kontenera bezpośrednio z przeglądarki bez sanityzacji. Parametr ten jest interpolowany do poleceń powłoki wykonywanych przez SSH na zarządzanych serwerach, co pozwala uwierzytelnionym członkom zespołu na wykonanie dowolnych poleceń OS na zdalnych serwerach.

Coolify przed wersją 4.0.0-beta.471 zawiera podatność w komponencie Livewire do importu bazy danych, która pozwala uwierzytelnionemu użytkownikowi na wstrzyknięcie komend przez nazwę kontenera importu. Brak blokady i walidacji sprawia, że właściwości kontenera i serwera sterowane przez klienta trafiają do poleceń powłoki.

W Coolify przed wersją 4.0.0-beta.466 komponent Logs::mount() wyszukuje zasoby po UUID bez ograniczenia do bieżącego zespołu, co pozwala uwierzytelnionemu użytkownikowi na dostęp do logów aplikacji innych zespołów poprzez podanie ich UUID.

Coolify przed wersją 4.0.0-beta.466 zawiera podatność polegającą na interpolacji sekretów log drain i wartości zmiennych środowiskowych do poleceń powłoki bez odpowiedniego kodowania. Umożliwia to uwierzytelnionemu użytkownikowi wstrzyknięcie poleceń wykonywanych na hoście.

Coolify przed wersją 4.0.0-beta.466 zawiera podatność polegającą na niewystarczającej walidacji ustawienia sentinel_token, które jest używane w poleceniach powłoki. Uwierzytelniony użytkownik mający dostęp do ustawień Sentinel serwera może wstrzyknąć składnię powłoki i wykonać polecenia na hoście podczas restartu Sentinela.

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.