Katalog podatności CVE

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.

Nieobsłużony wyjątek w interfejsie diagnostycznym kontrolerów 6000 i 7000 umożliwia uwierzytelnionemu i autoryzowanemu operatorowi wywołanie restartu kontrolera poprzez wysłanie specjalnych żądań, co prowadzi do tymczasowej odmowy usługi.

Nieobsłużony wyjątek w czytnikach T20 umożliwia uwierzytelnionemu i autoryzowanemu operatorowi wywołanie restartu poprzez wysłanie specjalnych żądań, co prowadzi do tymczasowej odmowy usługi. Podatność dotyczy systemu Command Centre w wersjach 9.50, 9.40, 9.30, 9.20 oraz wszystkich wcześniejszych.

Podatność nieprawidłowego przypisania uprawnień (CWE-266) w Command Centre Server umożliwia uwierzytelnionemu operatorowi z ograniczonymi uprawnieniami wykonanie operacji, do których normalnie nie byłby upoważniony. Problem dotyczy wersji 9.50 przed MR1, 9.40 przed MR3, 9.30 przed MR5, 9.20 przed MR7 oraz wszystkich wersji 9.10.

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