CVE-2026-72863
CriticalCVSS 9.9Exploitation Probability (EPSS)
Low risk31th percentile - higher than 31% of all known CVEs
Summary
Dokploy before version 0.29.13 in its WebSocket handlers (in-app terminals and log streamers) authenticate the session but never authorize it. They establish who the user is via validateRequest() and then proceed without consulting the role/permission model that every tRPC procedure enforces. Any authenticated member can therefore open an interactive shell into any container on the host, including the dokploy container that mounts the Docker socket, and from there obtain root on the host, escaping the application and crossing every tenant boundary.
Risk Assessment
An attacker can gain full control of the host and breach tenant isolation, leading to complete infrastructure compromise.
Recommendation
Update Dokploy to version 0.29.13 or later, which includes a fix for this vulnerability.
Other vulnerabilities in Dokploy
See all- CVE-2026-93425Critical
In Dokploy prior to 0.29.13, the patch.readRepoDirectories tRPC procedure passes the user-controlled repoPath value from patch.ts into a shell command in patch-repo.ts without safe argument quoting. An authenticated organization member with service:read permission can inject shell metacharacters into repoPath and execute arbitrary commands through child_process.exec as root in the Dokploy container. Because the standard deployment mounts /var/run/docker.sock, container-root command execution can be used to control Docker and compromise the host and its managed applications. This issue is fixed in version 0.29.13.
- CVE-2026-86059Critical
Dokploy is a free, self-hostable Platform as a Service (PaaS). Prior to 0.29.13, Dokploy organization members without Git provider access can retrieve plaintext provider credentials through github.one, gitlab.one, gitea.one, and bitbucket.one because those protected procedures return full provider rows without applying getAccessibleGitProviderIds or an organization check. The application.one route also returns nested GitHub, GitLab, Gitea, and Bitbucket relations from findApplicationById with GitHub App private keys, OAuth tokens, client secrets, webhook secrets, and app passwords even when hasGitProviderAccess is false.
- CVE-2026-82954Critical
A path traversal vulnerability was detected in Dokploy up to version 0.29.7, affecting the writeTraefikConfigInPath function in the file packages/server/src/utils/traefik/application.ts of the Settings component, through manipulation of the path argument. The attack can be launched remotely, and the exploit is public.
- CVE-2026-72902Critical
Dokploy prior to version 0.29.13 allows an authenticated user to execute arbitrary commands on a local or SSH-connected target server because registry.testRegistry and registry.testRegistryById interpolate the password field into an execAsyncRemote shell command instead of using safeDockerLoginCommand.
- CVE-2026-72901Critical
Dokploy prior to version 0.29.13 allows an authenticated low-privilege member to execute arbitrary commands on the control-plane host because the volumeName field accepted by volumeBackup.create and volumeBackup.runManually is interpolated without quoting in packages/server/src/utils/volume-backups/backup.ts and executed through child_process.exec, with Docker socket access making execution host/root-equivalent.
- CVE-2026-72886Critical
In Dokploy from version 0.29.2 to 0.29.13, schedule.create and schedule.update in schedule.ts derive serviceId from applicationId or composeId and execute the owner/admin host-schedule gate only in the alternative branch. This allows a member with access to one application to attach its applicationId to a dokploy-server schedule and run a supplied script as root through schedule.runManually. This issue is fixed in version 0.29.13.
- CVE-2026-72882Critical
In Dokploy version 0.28.8 and earlier, an authenticated user who can create or update file mounts for a service can inject shell metacharacters into filePath, causing Dokploy to execute attacker-controlled commands on the configured remote managed server over SSH. In the default deployment model, this yields direct remote host RCE from the web interface.
- CVE-2026-72880Critical
In Dokploy prior to 0.29.13, the apiCreateCertificate schema in schema/certificate.ts accepts a client-supplied certificatePath, and certificate.ts joins that value to the certificate root without confinement. An authenticated user with certificate create or delete permission can use certificatePath to write attacker-controlled certificate content outside the intended directory or delete an out-of-root directory. This vulnerability is fixed in 0.29.13.
- CVE-2026-72879Critical
In Dokploy prior to 0.29.8, the getRegistryCommands() function in upload.ts interpolates registry.password and registry.registryUrl directly into a shell command without escaping. An authenticated user with project access can configure malicious registry credentials and trigger a swarm deployment to execute arbitrary OS commands on the Dokploy server, read or modify host files, and access other containers through Docker. This issue is fixed in version 0.29.8.
- CVE-2026-72878Critical
In Dokploy prior to 0.29.13, the backup and restore pipeline constructs shell commands by directly interpolating user-controlled database fields into bash -c "..." and sh -c "..." strings, then executes them via child_process.exec(). An authenticated admin/owner can inject arbitrary OS commands that execute on the host machine running Dokploy (not just inside a container). This vulnerability is fixed in 0.29.13.
Original NVD description (English source)
Dokploy is a free, self-hostable Platform as a Service (PaaS). Prior to 0.29.13, Dokploy's WebSocket handlers (in-app terminals and log streamers) authenticate the session but never authorize it. They establish who the user is via validateRequest() and then proceed without consulting the role/permission model that every tRPC procedure enforces. Any authenticated member, can therefore open an interactive shell into any container on the host, including the dokploy container that mounts the Docker socket, and from there obtain root on the host, escaping the application and crossing every tenant boundary. This vulnerability is fixed in 0.29.13.

