CVE-2026-116068

W Dokploy przed wersją 0.29.13 procedura tRPC patch.readRepoDirectories przekazuje kontrolowaną przez użytkownika wartość repoPath z pliku patch.ts do polecenia powłoki w patch-repo.ts bez bezpiecznego cytowania argumentów. Uwierzytelniony członek organizacji z uprawnieniem service:read może wstrzyknąć metaznaki powłoki do repoPath i wykonać dowolne polecenia przez child_process.exec jako root w kontenerze Dokploy. Ponieważ standardowe wdrożenie montuje /var/run/docker.sock, wykonanie poleceń jako root w kontenerze może posłużyć do kontroli Dockera i przejęcia hosta oraz zarządzanych aplikacji. Problem naprawiono w wersji 0.29.13.

Dokploy to samodzielnie hostowana platforma PaaS. Przed wersją 0.29.13 członkowie organizacji bez dostępu do dostawcy Git mogą odczytać poświadczenia dostawcy w postaci jawnej poprzez procedury github.one, gitlab.one, gitea.one i bitbucket.one, ponieważ zwracają one pełne rekordy dostawcy bez sprawdzenia getAccessibleGitProviderIds lub przynależności do organizacji. Trasa application.one zwraca także zagnieżdżone relacje GitHub, GitLab, Gitea i Bitbucket z kluczami prywatnymi GitHub App, tokenami OAuth, sekretami klienta, sekretami webhooków i hasłami aplikacji, nawet gdy hasGitProviderAccess ma wartość false.

W Dokploy do wersji 0.29.7 wykryto podatność na przechodzenie po ścieżkach (path traversal) w funkcji writeTraefikConfigInPath pliku packages/server/src/utils/traefik/application.ts komponentu Settings, poprzez manipulację argumentem path. Atak może być przeprowadzony zdalnie, a exploit jest publiczny.

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.