CVE-2026-86059

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.

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.