Podatności Dokploy

Dokploy przed wersją 0.29.13 pozwala uwierzytelnionemu użytkownikowi na wykonanie dowolnych poleceń na lokalnym lub połączonym przez SSH serwerze docelowym, ponieważ funkcje registry.testRegistry i registry.testRegistryById interpolują pole hasła do polecenia powłoki execAsyncRemote zamiast używać bezpiecznego polecenia safeDockerLoginCommand.

Dokploy przed wersją 0.29.13 pozwala uwierzytelnionemu członkowi z niskimi uprawnieniami na wykonanie dowolnych poleceń na hoście kontrolnym, ponieważ pole volumeName przyjmowane przez volumeBackup.create i volumeBackup.runManually jest interpolowane bez cudzysłowów w packages/server/src/utils/volume-backups/backup.ts i wykonywane przez child_process.exec, a dostęp do gniazda Docker sprawia, że wykonanie jest równoważne z rootem na hoście.

W Dokploy od wersji 0.29.2 do 0.29.13 funkcje schedule.create i schedule.update w pliku schedule.ts pobierają serviceId z applicationId lub composeId i wykonują kontrolę właściciela/admina tylko w alternatywnej gałęzi. Umożliwia to członkowi z dostępem do jednej aplikacji dołączenie jej applicationId do harmonogramu dokploy-server i uruchomienie dostarczonego skryptu jako root przez schedule.runManually. Problem naprawiono w wersji 0.29.13.

W Dokploy w wersji 0.28.8 i wcześniejszych uwierzytelniony użytkownik, który może tworzyć lub aktualizować montowania plików dla usługi, może wstrzyknąć metaznaki powłoki do filePath, powodując wykonanie przez Dokploy poleceń kontrolowanych przez atakującego na skonfigurowanym zdalnym serwerze przez SSH. W domyślnym modelu wdrożenia prowadzi to do zdalnego wykonania kodu na hoście z poziomu interfejsu webowego.

W Dokploy przed wersją 0.29.13 schemat apiCreateCertificate w schema/certificate.ts akceptuje dostarczony przez klienta certificatePath, a usługa certificate.ts łączy tę wartość z katalogiem głównym certyfikatów bez ograniczeń. Uwierzytelniony użytkownik z uprawnieniami do tworzenia lub usuwania certyfikatów może użyć certificatePath do zapisu treści certyfikatu poza zamierzonym katalogiem lub usunięcia katalogu poza głównym. Podatność naprawiono w wersji 0.29.13.

W Dokploy przed wersją 0.29.8 funkcja getRegistryCommands() w pliku upload.ts interpoluje registry.password i registry.registryUrl bezpośrednio do polecenia powłoki bez odpowiedniego escapowania. Uwierzytelniony użytkownik z dostępem do projektu może skonfigurować złośliwe dane uwierzytelniające rejestru i wywołać wdrożenie swarm, aby wykonać dowolne polecenia systemu operacyjnego na serwerze Dokploy, czytać lub modyfikować pliki hosta oraz uzyskać dostęp do innych kontenerów przez Docker. Problem naprawiono w wersji 0.29.8.

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.

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.

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.

Dokploy przed wersją 0.29.13 zawiera podatność na wstrzykiwanie poleceń w funkcji writeTraefikConfigRemote, gdzie dane konfiguracji Traefik kontrolowane przez użytkownika są interpolowane do polecenia echo wykonywanego przez execAsyncRemote. Pojedyncze cudzysłowy w polach regex, nazwach użytkowników, domenach lub konfiguracji middleware mogą przerwać cytowanie i wykonać dowolne polecenia na zdalnych serwerach. Jest to niepełna poprawka CVE-2026-45630.

Dokploy przed wersją 0.29.13 zawiera podatność na wstrzykiwanie poleceń w subskrypcji backup.restoreBackupWithLogs, gdzie pola databaseName i backupFile są interpolowane do poleceń przywracania bazy danych bez odpowiedniego oddzielenia od składni powłoki. Uwierzytelniony użytkownik z uprawnieniami do przywracania kopii zapasowych może wstrzyknąć polecenia systemu operacyjnego wykonywane w kontekście hosta Dokploy.

Krytyczna podatność path traversal w Dokploy w wersji 0.26.5 i wcześniejszych. Uwierzytelnieni użytkownicy mogą zapisywać dowolne pliki w systemie plików podczas wdrażania aplikacji, co w połączeniu z funkcją zdalnego serwera umożliwia zdalne wykonanie kodu i pełne przejęcie serwera.

Dokploy w wersji 0.26.6 i wcześniejszych zawiera podatność wstrzykiwania komend w punkcie końcowym WebSocket /docker-container-logs. Parametry tail i since nie są walidowane i są bezpośrednio konkatenowane do komend powłoki, co pozwala uwierzytelnionym użytkownikom na wykonanie dowolnych komend z uprawnieniami roota.

Dokploy w wersji 0.26.7 i wcześniejszych nie wymusza kontroli organizacji/roli w routerze harmonogramu. Każdy uwierzytelniony użytkownik może tworzyć, aktualizować, uruchamiać lub usuwać harmonogramy innych organizacji, jeśli zna scheduleId/serverId. Typy harmonogramów server i dokploy-server umożliwiają wykonanie kodu na hoście lub zdalnym serwerze (RCE).

Dokploy w wersjach od 0.27.0 do 0.29.3 zawiera zakodowany na stałe klucz BETTER_AUTH_SECRET ("better-auth-secret-123456789"), co pozwala nieuwierzytelnionemu atakującemu na sfałszowanie tokenów JWT do weryfikacji e-mail, automatyczne zalogowanie jako administrator i wykonanie poleceń na hoście przez wbudowany terminal SSH.

Dokploy 0.28.8 i wcześniejsze zawiera podatność na wstrzykiwanie poleceń OS w punkcie końcowym tRPC application.updateTraefikConfig. Uwierzytelnieni użytkownicy z rolą admin/owner mogą wykonywać dowolne polecenia systemowe na zdalnych serwerach przez niesanitowaną interpolację powłoki echo.

Dokploy 0.28.8 i wcześniejsze zawiera podatność na wstrzykiwanie poleceń OS w punkcie końcowym WebSocket /listen-deployment. Każdy członek organizacji może wykonywać dowolne polecenia systemowe na zdalnych serwerach zarządzanych przez Dokploy, prowadząc do pełnego przejęcia serwera.

Dokploy, samodzielnie hostowana platforma PaaS, w wersji 0.29.2 i wcześniejszych konstruuje polecenia powłoki z użyciem literałów szablonów JavaScript i wykonuje je przez child_process.exec() bez odpowiedniego escapowania danych wejściowych użytkownika.

W Dokploy w wersji 0.29.1 i wcześniejszych wykryto podatność na wstrzykiwanie poleceń w funkcji przesyłania plików Docker. Parametr destinationPath nie jest odpowiednio sanityzowany i jest bezpośrednio interpolowany do polecenia powłoki, co pozwala uwierzytelnionemu użytkownikowi na wykonanie dowolnych poleceń systemowych na hoście Dokploy.

Dokploy w wersji 0.26.6 i niższych ma podatność na wstrzykiwanie poleceń OS przez parametr appName z powodu niedostatecznego oczyszczania danych wejściowych i interpolacji w powłoce.

Dokploy to samodzielnie hostowana platforma jako usługa (PaaS). Przed wersją 0.29.6 procedura aktualizacji użytkownika nie usuwa innych sesji po zmianie hasła, co pozwala skompromitowanemu tokenowi sesji pozostać ważnym do trzech dni po zmianie hasła. Problem naprawiono w wersji 0.29.6.

Dokploy przed wersją 0.29.6 pozwala użytkownikowi z uprawnieniem member:create na zaproszenie konta z rolą właściciela, a uprzywilejowany użytkownik self-hosted może utworzyć konto z dowolną rolą, co umożliwia trwałe przejęcie organizacji, ponieważ ról właściciela nie można zdegradować.

Dokploy to darmowa, samohostowana platforma jako usługa (PaaS). Przed wersją 0.29.13 parametr dockerContextPath akceptowany w aplikacji przepływa przez funkcję getDockerContextPath do niecytowanego polecenia cd w pliku docker-file.ts przed wykonaniem przez execAsync, co pozwala uwierzytelnionemu edytorowi aplikacji na wykonanie dowolnych poleceń na hoście Dokploy. Problem został naprawiony w wersji 0.29.13.

W Dokploy przed wersją 0.29.13 wykryto podatność w funkcji sanitizeCommand w pliku compose.ts, która tylko przycina białe znaki i usuwa otaczające cudzysłowy z compose.command przed interpolacją do exportEnvCommand i poleceń docker. Uwierzytelniony użytkownik, który może aktualizować usługę Compose, może wstrzyknąć metaznaki powłoki i wykonać dowolne polecenia na hoście Dokploy. Problem został naprawiony w wersji 0.29.13.

W Dokploy przed wersją 0.29.13 wykryto podatność w handlerach WebSocket, które walidują członkostwo w organizacji, ale nie egzekwują checkServiceAccess, accessedServerIds ani accessedServices. Uwierzytelniony członek organizacji może uzyskać dostęp do terminala root oraz odczytywać logi i statystyki dla ograniczonych serwerów i usług. Problem został naprawiony w wersji 0.29.13.

Dokploy przed wersją 0.29.13 zawiera podatność na wstrzykiwanie poleceń w konstruktorach poleceń tworzenia i przywracania kopii zapasowych baz danych. Uwierzytelniony administrator z uprawnieniami do tworzenia baz danych i konfigurowania kopii zapasowych może użyć spreparowanych pól konfiguracyjnych do wykonania dowolnych poleceń w kontenerach PostgreSQL, MariaDB, MySQL, MongoDB lub LibSQL, co może prowadzić do ujawnienia danych i poświadczeń oraz potencjalnej eskalacji uprawnień.

Dokploy przed wersją 0.29.13 zawiera podatność na wstrzykiwanie poleceń w funkcji settings.readTraefikFile. Użytkownik z uprawnieniami traefikFiles.read może wykonać dowolne polecenia na zarządzanym serwerze poprzez metaznaki powłoki w ścieżce configPath.

Dokploy przed wersją 0.29.13 zawiera podatność na wstrzykiwanie poleceń w funkcji cloneGitRepository. Uwierzytelniony użytkownik z dostępem do aplikacji może wykonać dowolne polecenia systemu operacyjnego na hoście Dokploy, ustawiając złośliwy niestandardowy adres URL Git i wyzwalając wdrożenie.

Dokploy przed wersją 0.29.13 nie usuwa wrażliwych pól (githubClientSecret, githubPrivateKey, githubWebhookSecret) z odpowiedzi API dotyczących dostawców Git. Użytkownik z uprawnieniami tylko do odczytu usług może pobrać sekrety dostawcy Git innego użytkownika, nawet gdy hasGitProviderAccess jest ustawione na false.

Dokploy przed wersją 0.29.13 zawiera podatność w nieuwierzytelnionej trasie /api/providers/github/setup, która ufa wartościom gh_init organizationId i userId z parametru state i wywołuje createGithub, co pozwala atakującemu na wstawienie dostawcy GitHub App zawierającego client_secret, webhook_secret i klucz prywatny PEM do innej organizacji.

Dokploy przed wersją 0.29.13 zawiera podatność na wstrzykiwanie poleceń w funkcji buildRemoteDocker(), gdzie wartość dockerImage jest bezpośrednio interpolowana do polecenia docker pull. Uwierzytelniony użytkownik z dostępem do projektu może wykonać dowolne polecenia systemu operacyjnego na serwerze Dokploy.

Dokploy przed wersją 0.29.13 ma podatność w obsłudze WebSocket, gdzie walidacja sesji nie sprawdza autoryzacji dostępu do żądanego serwera. Uwierzytelniony użytkownik może połączyć się z terminalem na hoście Dokploy bez wymaganej roli organizacyjnej lub sprawdzenia dostępu do serwera.

Dokploy przed wersją 0.29.13 zawiera podatność w funkcji createCommand(), która konstruuje polecenia powłoki poprzez interpolację nazw usług i konfiguracji compose do ciągów poleceń bash. Gdy wdrożony jest compose z złośliwie spreparowaną nazwą lub definicją usługi, metaznaki powłoki są interpretowane jako separatory poleceń, co pozwala na wykonanie dowolnych poleceń na hoście Docker.

Dokploy od wersji 0.28.7 do 0.29.13 ma podatność w mutacji tRPC server.remove, która nie weryfikuje, czy identyfikator organizacji serwera zgadza się z aktywną organizacją sesji. Uwierzytelniony właściciel lub administrator z uprawnieniami do usuwania serwera w jednej organizacji może usunąć serwer i rekordy wdrożeń innej organizacji oraz otrzymać powiązany klucz prywatny SSH.

W Dokploy w wersji 0.19.0 i wcześniejszych, middleware protectedProcedure tylko weryfikuje uwierzytelnienie użytkownika, ale nie wymusza zakresu organizacji. Każdy endpoint musi indywidualnie weryfikować, czy zasób należy do organizacji użytkownika. Dotyczy to wielu endpointów w różnych plikach.

W Dokploy w wersji 0.29.0 i wcześniejszych funkcja deleteRegistry wykonuje polecenie docker logout bez odpowiedniego escapowania argumentu registryUrl, co umożliwia wstrzyknięcie poleceń powłoki. W przeciwieństwie do funkcji docker login, która używa shEscape(), brak zabezpieczeń w deleteRegistry stwarza podatność na ataki przez spreparowany adres URL rejestru.