Katalog podatności CVE

W Dokploy przed wersją 0.29.13 potok tworzenia kopii zapasowych i przywracania konstruuje polecenia powłoki, bezpośrednio interpolując kontrolowane przez użytkownika pola bazy danych do ciągów bash -c "..." i sh -c "...", a następnie wykonuje je przez child_process.exec(). Uwierzytelniony administrator/właściciel może wstrzyknąć dowolne polecenia systemu operacyjnego, które wykonują się na hoście, na którym działa Dokploy (nie tylko wewnątrz kontenera). Podatność naprawiono w wersji 0.29.13.

W Dokploy przed wersją 0.29.13 pole dockerImage jest interpolowane bez cudzysłowów do poleceń powłoki w buildRemoteDocker() w pliku docker.ts i walidowane tylko jako opcjonalny ciąg znaków. Uwierzytelniony użytkownik z uprawnieniami do tworzenia lub aktualizacji aplikacji może użyć podstawienia poleceń w dockerImage, aby wykonać dowolne polecenia na lokalnym hoście budowania lub zdalnym celu SSH, ujawniając sekrety hosta i innych projektów. Problem naprawiono w wersji 0.29.13.

W Dokploy przed wersją 0.29.13 funkcje swarm.getNodes, swarm.getNodeInfo, swarm.getNodeApps i swarm.getAppInfos w pliku swarm.ts akceptują serverId innej organizacji bez sprawdzenia własności activeOrganizationId, a getNodeInfo w docker.ts interpoluje nodeId do execAsyncRemote, umożliwiając wywołującemu z uprawnieniami server:read wykonanie dowolnych poleceń jako skonfigurowany użytkownik SSH na serwerze innego najemcy. Problem naprawiono w wersji 0.29.13.

TBEA TLogger V2.1.0.0B0.0.0.0 zawiera obejście uwierzytelniania w swoim serwerze WWW. Po wcześniejszym uwierzytelnieniu użytkownika na urządzeniu, nieuwierzytelniony atakujący może bezpośrednio uzyskać dostęp do chronionych funkcji przez punkt końcowy /index.asp bez podawania ważnych poświadczeń. Umożliwia to atakującemu dostęp do funkcji przeznaczonych dla uwierzytelnionych użytkowników i może ujawnić lub zmodyfikować konfigurację i dane urządzenia. Wylogowanie z ominiętego stanu może dodatkowo spowodować awarię serwera WWW.

Nieuwierzytelniona podatność na wstrzyknięcie SQL istnieje w serwerze WWW TBEA TLogger V2.1.0.0B0.0.0.0. Wiele punktów końcowych HTTP włącza kontrolowane przez atakującego parametry bezpośrednio do zapytań SQLite bez wystarczającej walidacji lub parametryzacji. Zdalny nieuwierzytelniony atakujący może wykorzystać te punkty końcowe do odczytu, modyfikacji lub usunięcia danych przechowywanych w bazie danych CCU.db urządzenia.

Zakodowane na stałe lub domyślne poświadczenia konta root w TBEA TLogger V2.1.0.0B0.0.0.0 umożliwiają nieuwierzytelnionemu zdalnemu atakującemu uzyskanie dostępu na poziomie root do urządzenia przez wystawioną usługę SSH. Hasło root można odzyskać z hasha przechowywanego w /etc/shadow i użyć do uwierzytelnienia w usłudze SSH. Skuteczne wykorzystanie zapewnia pełną kontrolę administracyjną nad urządzeniem.

Dokploy przed wersją 0.29.13 nie waliduje pól bitbucketOwner i bitbucketRepository podczas zapisywania dostawcy Bitbucket, a następnie interpoluje je do poleceń git clone wykonywanych przez execAsync lub execAsyncRemote. Umożliwia to członkowi z uprawnieniami do wdrażania usług wykonanie dowolnych poleceń systemu operacyjnego na hoście Dokploy lub serwerze docelowym.

Dokploy przed wersją 0.29.13 w subskrypcji tRPC backup.restoreBackupWithLogs przekazuje parametr databaseName do funkcji przywracania, gdzie polecenia PostgreSQL, MariaDB, MySQL i MongoDB osadzają tę wartość w zagnieżdżonym tekście powłoki wykonywanym przez Node.js exec. Uwierzytelniony użytkownik z uprawnieniem backup:restore może dostarczyć spreparowany databaseName, który powłoka /bin/sh rozszerza przed docker exec, co prowadzi do wykonania dowolnych poleceń w kontekście hosta z uprawnieniami Docker.

Dokploy przed wersją 0.29.13 w pliku destination.ts interpoluje pola accessKey, secretAccessKey, region, endpoint, provider i bucket z destination.testConnection do polecenia rclone ls wykonywanego przez child_process.exec. Ścieżka z uprawnieniem "destination", "create" pozwala członkowi organizacji o niskich uprawnieniach na dotarcie do mutacji, zamknięcie cytowanego argumentu spreparowanym polem i wykonanie dowolnych poleceń w kontenerze root Dokploy, który ma dostęp do gniazda Docker hosta.

Dokploy od wersji 0.29.3 do 0.29.13 ma niekompletną poprawkę dla CVE-2026-45628, pozostawiając pola gałęzi w schema/compose.ts bez walidacji po stronie serwera, co pozwala na bezpośrednie żądanie compose.update do przechowywania złośliwego customGitBranch, branch, gitlabBranch, bitbucketBranch lub giteaBranch. Uwierzytelniony użytkownik o niskich uprawnieniach może wywołać compose.deploy, który przekazuje zapisaną gałąź do poleceń git clone opartych na powłoce, co prowadzi do wykonania dowolnych poleceń na hoście.

Dokploy przed wersją 0.29.13 w operacji compose.update przechowuje niezweryfikowany composePath, który jest interpolowany do poleceń docker compose -f, docker stack deploy -c i touch wykonywanych przez /bin/sh -c. Uwierzytelniony członek z uprawnieniami do zapisu i wdrażania compose może dostarczyć spreparowany composePath, wywołać compose.deploy lub startCompose i wykonać dowolne polecenia systemu operacyjnego w kontekście hosta z uprawnieniami Docker.

Dokploy przed wersją 0.29.13 w lokalnej gałęzi /docker-container-terminal uwierzytelnia za pomocą validateRequest, ale nie autoryzuje kontrolowanego przez atakującego containerId względem roli, organizacji lub dostępu do usługi wywołującego przed przekazaniem go do `docker exec`, co pozwala każdemu uwierzytelnionemu członkowi uzyskać powłokę root w dowolnych kontenerach na samodzielnie hostowanej instancji.

Dokploy przed wersją 0.29.13 w handlerach WebSocket (terminalach w aplikacji i strumieniach logów) uwierzytelnia sesję, ale nigdy jej nie autoryzuje. Ustalają tożsamość użytkownika przez validateRequest(), a następnie działają bez konsultacji z modelem ról/uprawnień, który egzekwują wszystkie procedury tRPC. Każdy uwierzytelniony członek może otworzyć interaktywną powłokę w dowolnym kontenerze na hoście, w tym w kontenerze dokploy montującym gniazdo Docker, a stamtąd uzyskać root na hoście, wychodząc poza aplikację i przekraczając granice dzierżawców.

Metabase umożliwia nieuwierzytelnionemu atakującemu wstrzyknięcie dowolnego SQL przez publicznie udostępnioną kartę lub pulpit nawigacyjny, który udostępnia parametr filtra wymiaru.

Dokploy przed wersją 0.29.13 w funkcjach wdrażania usług baz danych (mariadb.ts, mongo.ts, mysql.ts, postgres.ts, redis.ts i libsql.ts) przekazuje kontrolowane przez użytkownika pola dockerImage bez cudzysłowów do poleceń docker pull ${dockerImage} w ścieżce zdalnego serwera.

Dokploy przed wersją 0.29.13 zawiera podatność na wstrzykiwanie poleceń w funkcji addHostToKnownHostsCommand, gdzie domena z user-controlled customGitUrl jest interpolowana do polecenia ssh-keyscan bez odpowiedniego cytowania. Uwierzytelniony użytkownik z uprawnieniami do wdrażania usług i dołączonym kluczem SSH może wykonać dowolne polecenia na hoście Dokploy podczas wdrażania.

Dokploy przed wersją 0.29.13 zawiera podatność na wstrzykiwanie poleceń w endpointcie backup.listBackupFiles, gdzie parametr search jest interpolowany do polecenia rclone lsjson bez odpowiedniego zabezpieczenia. Uwierzytelniony użytkownik z uprawnieniami backup:read może wykonać dowolne polecenia na hoście Dokploy.

Dokploy w wersji 0.29.8 i wcześniejszych zawiera podatność polegającą na braku weryfikacji przynależności destinationId do organizacji w endpointach backup.create, backup.update i backup.restoreBackupWithLogs. Uwierzytelniony użytkownik z uprawnieniami do tworzenia kopii zapasowych w jednej organizacji może uzyskać dostęp do danych S3 innej organizacji, odczytać obiekty kopii zapasowych lub przekierować i zatruć kopie zapasowe między dzierżawcami.

Dokploy przed wersją 0.29.13 zawiera podatność na wstrzykiwanie poleceń w endpointach testowania poświadczeń rejestru i zarządzania klastrem Docker Swarm, gdzie wartości kontrolowane przez użytkownika są interpolowane do poleceń powłoki bez odpowiedniego cytowania. Podatna ścieżka zdalna używa execAsyncRemote, co pozwala na wykonanie dowolnych poleceń na zdalnych serwerach.