Podatności Coolify

Coolify to narzędzie open-source do zarządzania serwerami, aplikacjami i bazami danych. W wersjach do v4.0.0-beta.434 istnieje podatność, która pozwala atakującemu zainicjować reset hasła ofiary i zmodyfikować nagłówek Host w żądaniu na złośliwą wartość. Ofiara otrzyma e-mail z linkiem do złośliwego hosta, a po kliknięciu token resetu zostanie wysłany na serwer atakującego, co umożliwia przejęcie konta.

Coolify to narzędzie typu open-source do samodzielnego zarządzania serwerami, aplikacjami i bazami danych. W wersjach do v4.0.0-beta.434 włącznie, w polach źródła git zasobu występuje podatność na wstrzyknięcie poleceń, umożliwiająca użytkownikowi z niskimi uprawnieniami (członek) wykonanie poleceń systemowych jako root na instancji Coolify. Na dzień publikacji nie jest jasne, czy dostępna jest poprawka.

Coolify to narzędzie open-source do zarządzania serwerami, aplikacjami i bazami danych. W wersjach do v4.0.0-beta.434 włącznie, użytkownik z niskimi uprawnieniami (członek) może zobaczyć i użyć linków zaproszeniowych wysłanych do administratora. Jeśli użyje linku przed uprawnionym odbiorcą, może zalogować się jako administrator, co prowadzi do eskalacji uprawnień.

Coolify do wersji v4.0.0-beta.434 zawiera podatność, która pozwala użytkownikowi z niskimi uprawnieniami (członek) zaprosić użytkownika z wysokimi uprawnieniami (administratora). Mimo że pierwsza próba zaproszenia kończy się błędem, ponowne kliknięcie przycisku zaproszenia powoduje powodzenie operacji. Dzięki temu atakujący może zaprosić siebie jako administratora, a następnie zresetować hasło i zalogować się z uprawnieniami administratora.

Coolify w wersjach do v4.0.0-beta.420.6 zawiera podatność na trwały atak XSS w procesie tworzenia projektu. Uwierzytelniony użytkownik z niskimi uprawnieniami może utworzyć projekt o złośliwej nazwie zawierającej JavaScript, który wykona się w przeglądarce administratora podczas usuwania projektu lub zasobu. Wersja 4.0.0-beta.420.7 zawiera poprawkę.

Coolify przed wersją 4.0.0-beta.420.7 zawiera podatność zdalnego wykonania kodu (RCE) w procesie wdrażania aplikacji. Użytkownik z niskimi uprawnieniami może wstrzyknąć dowolne dyrektywy Docker Compose podczas tworzenia lub aktualizacji projektu, co pozwala na zamontowanie systemu plików hosta i wykonanie poleceń z uprawnieniami roota, omijając izolację kontenerów.

W Coolify przed wersją 4.0.0-beta.471, trasy bootstrap websocket terminala sprawdzają tylko uwierzytelnienie, ale nie egzekwują autoryzacji terminala. Umożliwia to członkowi zespołu z niskimi uprawnieniami połączenie się z trasami terminala i wykonywanie poleceń na serwerach zespołu.

W Coolify przed wersją 4.0.0-beta.471, trasy bootstrap WebSocket terminala nie wymuszały oczekiwanego middleware autoryzacji, co pozwalało uwierzytelnionemu użytkownikowi na dostęp do funkcji terminala dla zasobów spoza autoryzowanego zakresu i potencjalne wykonanie poleceń.

Coolify przed wersją 4.0.0-beta.464 zawiera podatność w akcji Livewire cloneTo() w pliku ResourceOperations.php. Mechanizm autoryzacji sprawdza tylko źródłowy zasób, ale docelowe zasoby są rozwiązywane bez uwzględnienia zakresu dzierżawy (unscoped Eloquent lookups), co pozwala uwierzytelnionemu użytkownikowi klonować zasoby do miejsc docelowych należących do innych zespołów i uzyskiwać dostęp do zasobów między dzierżawami.

Coolify przed wersją 4.0.0-beta.469 zawiera podatność na zdalne wstrzykiwanie poleceń w procesie wdrażania aplikacji. Uwierzytelniony użytkownik z uprawnieniami do zapisu aplikacji może wykorzystać pola takie jak dockerfile_location i polecenia wdrożeniowe do zdalnego wykonania kodu i wycieku wrażliwych zmiennych środowiskowych przez logi wdrożeń.

Coolify przed wersją 4.0.0-beta.474 zawiera podatność polegającą na braku walidacji własności serwera w komponentach Livewire. Komponenty te akceptują parametry server_id i destination_uuid z zapytań URL bez sprawdzania przynależności do zespołu, co umożliwia wdrożenie zasobów na serwerach innych zespołów.

Coolify to narzędzie open-source do samodzielnego hostowania do zarządzania serwerami, aplikacjami i bazami danych. W wersjach do v4.0.0-beta.434 włącznie, użytkownicy z niskimi uprawnieniami mogą zobaczyć klucz prywatny użytkownika root na instancji Coolify. Umożliwia to połączenie SSH i uwierzytelnienie jako root przy użyciu tego klucza. W chwili publikacji nie jest jasne, czy dostępna jest poprawka.

Coolify to narzędzie open-source do samodzielnego hostowania do zarządzania serwerami, aplikacjami i bazami danych. Przed wersją 4.0.0-beta.445 parametry pochodzące z docker-compose.yaml nie są sanityzowane, gdy są używane w poleceniach. Jeśli ofiara utworzy aplikację z repozytorium atakującego (używając build pack "docker compose"), atakujący może wykonać polecenia na instancji Coolify jako root. Wersja 4.0.0-beta.445 naprawia ten problem.

Coolify to narzędzie open-source do samodzielnego hostowania do zarządzania serwerami, aplikacjami i bazami danych. Przed wersją 4.0.0-beta.420.7 pole Git Repository podczas tworzenia projektu jest podatne na wstrzyknięcie poleceń. Dane wejściowe użytkownika nie są odpowiednio sanityzowane, co pozwala atakującym na wstrzyknięcie dowolnych poleceń powłoki, które są wykonywane na serwerze podczas procesu wdrażania. Zwykły użytkownik może wykorzystać tę podatność. Wersja 4.0.0-beta.420.7 zawiera poprawkę.

Podatność typu stored XSS w Coolify przed wersją v4.0.0-beta.420.6 umożliwia uwierzytelnionemu użytkownikowi z niskimi uprawnieniami wstrzyknięcie złośliwego JavaScriptu w nazwę projektu. Kod wykonuje się w przeglądarce administratora podczas próby usunięcia projektu lub powiązanego zasobu.

W systemie Coolify do wersji 4.1.1 wykryto podatność polegającą na braku autoryzacji w mechanizmie obsługi polityk (Policy Handler). Nieznana funkcja w pliku /app/Policies/ umożliwia zdalne wykorzystanie luki bez wymaganych uprawnień. Exploit jest publicznie dostępny.

Coolify przed wersją 4.0.0-beta.469 zawiera podatność na wstrzykiwanie poleceń w funkcji generate_healthcheck_commands(). Parametry health_check_host, health_check_method i health_check_path są bezpośrednio interpolowane do poleceń powłoki bez odpowiedniej sanityzacji, co umożliwia uwierzytelnionym użytkownikom wykonanie dowolnych poleceń w kontenerach wdrożeniowych.

W Coolify przed wersją 4.0.0-beta.474 pola haseł baz danych (redis_password, keydb_password, dragonfly_password, clickhouse_admin_user, clickhouse_admin_password, postgres_user, mysql_user) są walidowane tylko jako 'string' bez sprawdzania bezpieczeństwa powłoki. Wartości te są następnie interpolowane bezpośrednio do poleceń Docker Compose YAML bez żadnego escapowania, co umożliwia wstrzyknięcie złośliwych komend.

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.

W Coolify przed wersją 4.0.0-beta.474 tokeny API Sanctum nie wygasały, co oznacza, że wyciekły token zachowywał dostęp bezterminowo, dopóki nie został ręcznie unieważniony. Luka została naprawiona w wersji 4.0.0-beta.474.

Coolify przed wersją 4.0.0-beta.474 zawiera podatność polegającą na tym, że walidacja punktu końcowego S3 sprawdza tylko format URL, a funkcja testConnection() wysyła żądanie po stronie serwera do skonfigurowanego punktu końcowego. Umożliwia to uwierzytelnionemu użytkownikowi z uprawnieniami do zarządzania pamięcią masową zmuszenie Coolify do żądania wewnętrznych lub metadanych URL-i.

W Coolify przed wersją 4.0.0-beta.474, endpoint do przesyłania plików przywracania kopii zapasowej bazy danych nie walidował typu ani rozmiaru pliku. Umożliwiało to uwierzytelnionemu użytkownikowi przesłanie nieoczekiwanych lub zbyt dużych plików, co mogło wpłynąć na dostępność usługi.

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, oprogramowanie pośredniczące TrustProxies ufa wszystkim proxy, akceptując nagłówek X-Forwarded-Host z dowolnego źródła. TrustHosts ma cykliczną zależność buforowania, która uniemożliwia walidację hostów. Nieuwierzytelniony atakujący może wywołać reset hasła i przechwycić link z fałszywą domeną, kradnąc token i przejmując konto.

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

Podatność w Coolify przed wersją 4.0.0-beta.471 pozwala uwierzytelnionemu użytkownikowi na skonfigurowanie źródła GitHub App z polem api_url, które jest używane jako bazowy URL do żądań HTTP po stronie serwera bez blokowania adresów prywatnych lub punktów końcowych metadanych chmury. Umożliwia to wykonywanie żądań do wewnętrznych usług lub metadanych chmury.

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.

Coolify przed wersją 4.0.0-beta.471 zawiera podatność na wstrzykiwanie poleceń w funkcji DatabaseBackupJob. Uwierzytelniony użytkownik z uprawnieniami do zarządzania bazami danych może wykonać dowolne polecenia na zarządzanych serwerach poprzez manipulację danymi uwierzytelniającymi bazy danych lub nazwami kolekcji MongoDB.

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

Podatność w Coolify przed wersją 4.0.0-beta.474 pozwala na wykonanie dowolnych poleceń na serwerze poprzez brak odpowiedniego escapowania w metodzie buildHelperImage. Atakujący może ustawić pole dev_helper_version i wywołać budowę obrazu pomocniczego w środowisku deweloperskim.

W Coolify przed wersją 4.0.0-beta.474 endpoint POST /api/feedback nie wymaga uwierzytelnienia, nie ma ograniczeń szybkości ani walidacji danych wejściowych. Pozwala to na przesyłanie dowolnej treści bezpośrednio do webhooka Discord, co umożliwia spam, wstrzykiwanie treści i nadużycie webhooka.

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, komponent ActivityMonitor Livewire udostępnia publiczną właściwość $activityId bez atrybutu #[Locked]. Umożliwia to uwierzytelnionemu użytkownikowi wyliczanie rekordów aktywności ze wszystkich zespołów i odczytywanie pełnego wyjścia poleceń z zdalnych procesów SSH, co może ujawnić tajemnice, pliki konfiguracyjne i szczegóły infrastruktury.

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.

W Coolify przed wersją 4.0.0-beta.471 komponent Livewire Settings/Updates nie sprawdza uprawnień isInstanceAdmin w metodzie mount, co umożliwia nieuprawnionym użytkownikom dostęp do strony ustawień aktualizacji i potencjalną modyfikację konfiguracji automatycznych aktualizacji lub inicjowanie sprawdzania aktualizacji.

W Coolify od wersji 4.0.0-beta.451 do 4.0.0-beta.470, obsługa kopii zapasowych baz danych MongoDB nie walidowała w pełni znaków specjalnych w nazwach kolekcji, co umożliwiało wysoko uprzywilejowanemu atakującemu wstrzyknięcie komend. Problem został naprawiony w wersji 4.0.0-beta.471.

Coolify przed wersją 4.0.0-beta.466 posiada podatność, w której punkty końcowe API do walidacji mutacji są chronione jedynie uprawnieniami do odczytu. Pozwala to tokenom API z zakresem tylko do odczytu na wykonywanie operacji zmieniających stan, takich jak walidacja tokenów chmurowych i serwerów.

W Coolify przed wersją 4.0.0-beta.464 wykryto podatność na wstrzykiwanie poleceń w funkcji zarządzania certyfikatami CA. Uwierzytelniony użytkownik może wykonać dowolne polecenia jako skonfigurowany użytkownik SSH na zarządzanym serwerze.

Coolify przed wersją 4.0.0-beta.464 zawiera podatność w endpointcie `GET /api/v1/servers/{server_uuid}/domains?uuid={app_uuid}`, która omija ograniczenia zespołów (team scoping) przy podaniu opcjonalnego parametru `uuid`. Każdy uwierzytelniony użytkownik API może wyliczyć nazwy domen (FQDN) aplikacji należących do innych zespołów.

Coolify przed wersją 4.0.0-beta.464 zawiera podatność polegającą na braku odpowiedniego escapowania apostrofów w funkcji executeInDocker(). Pola docker_compose_custom_build_command i docker_compose_custom_start_command są interpolowane bezpośrednio, co umożliwia atakującemu wstrzyknięcie kodu bash i wykonanie poleceń na hoście zarządzanym przez Coolify.

Coolify przed wersją 4.0.0-beta.464 zawiera podatność w endpointcie GET /api/v1/deployments/{uuid}, która pozwala uwierzytelnionemu użytkownikowi na dostęp do szczegółów wdrożeń dowolnego zespołu, z pominięciem autoryzacji opartej na zespole. Problem wynika z braku wykorzystania $teamId z tokena uwierzytelniającego do ograniczenia zapytania do bazy danych.

Coolify przed wersją 4.0.0-beta.461 używa niebezpiecznego operatora porównania ciągów (!==) do walidacji sekretnego tokena webhooka GitLab. Pozwala to atakującemu na stopniowe odgadnięcie tokena poprzez pomiar różnic w czasie odpowiedzi (atak timingowy).