Dokploy vulnerabilities

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.

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.

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.

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.

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.

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.

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.

In Dokploy prior to 0.29.13, the dockerImage field is interpolated without quoting into shell commands in buildRemoteDocker() in docker.ts and is validated only as an optional string. An authenticated user with application create or update permission can use shell command substitution in dockerImage to execute arbitrary commands on the local build host or a remote SSH build target, exposing host secrets and other projects. This issue is fixed in version 0.29.13.

In Dokploy prior to 0.29.13, swarm.getNodes, swarm.getNodeInfo, swarm.getNodeApps, and swarm.getAppInfos in swarm.ts accept another organization’s serverId without an activeOrganizationId ownership check, and getNodeInfo in docker.ts interpolates nodeId into execAsyncRemote, allowing a caller with server:read permission to execute arbitrary commands as the configured SSH user on another tenant’s server. This issue is fixed in version 0.29.13.

Dokploy before version 0.29.13 does not validate the bitbucketOwner and bitbucketRepository fields when saving a Bitbucket provider, and later interpolates them into git clone commands executed via execAsync or execAsyncRemote. This allows a member with service deployment permission to execute arbitrary operating system commands on the Dokploy host or target server.

Dokploy before version 0.29.13 in the backup.restoreBackupWithLogs tRPC subscription passes the databaseName parameter to restore builders, where PostgreSQL, MariaDB, MySQL, and MongoDB commands embed the value in nested shell text executed by Node.js exec. An authenticated user with backup:restore permission can supply a crafted databaseName that the host /bin/sh expands before docker exec, resulting in arbitrary commands running in the Docker-privileged host context.

Dokploy before version 0.29.13 in destination.ts interpolates the accessKey, secretAccessKey, region, endpoint, provider, and bucket fields from destination.testConnection into an rclone ls command executed through child_process.exec. The withPermission("destination", "create") path permits a low-privileged organization member to reach the mutation, close a quoted argument with a crafted field, and execute arbitrary commands in the root Dokploy container, which has access to the host Docker socket.

Dokploy from version 0.29.3 until 0.29.13 has an incomplete fix for CVE-2026-45628, leaving branch fields in packages/server/src/db/schema/compose.ts without server-side validation, allowing a direct compose.update request to store a malicious customGitBranch, branch, gitlabBranch, bitbucketBranch, or giteaBranch. A low-privileged authenticated user can trigger compose.deploy, which passes the stored branch to shell-based Git clone commands, resulting in arbitrary host command execution.

Dokploy before version 0.29.13 in the compose.update operation stores an unvalidated composePath that is interpolated into docker compose -f, docker stack deploy -c, and touch shell commands executed through /bin/sh -c. An authenticated member with compose write and deploy permission can supply a crafted composePath, trigger compose.deploy or startCompose, and execute arbitrary operating-system commands in the Docker-privileged Dokploy host context.

Dokploy before version 0.29.13 in the local branch of /docker-container-terminal authenticates with validateRequest but does not authorize the attacker-controlled containerId against the caller's role, organization, or service access before passing it to `docker exec`, allowing any authenticated member to obtain a root shell in arbitrary containers on a self-hosted instance.

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.

Dokploy before version 0.29.13 in the mariadb.ts, mongo.ts, mysql.ts, postgres.ts, redis.ts, and libsql.ts database service deployment functions pass user-controlled dockerImage fields unquoted into docker pull ${dockerImage} shell commands on the remote-server code path.

Dokploy before version 0.29.13 contains a command injection vulnerability in addHostToKnownHostsCommand, where the domain from user-controlled customGitUrl is interpolated into the ssh-keyscan command without proper quoting. An authenticated user with service deployment permission and an attached SSH key can execute arbitrary commands on the Dokploy host during deployment.

Dokploy before version 0.29.13 contains a command injection vulnerability in the backup.listBackupFiles endpoint, where the search parameter is interpolated into the rclone lsjson command without proper sanitization. An authenticated user with backup:read permission can execute arbitrary commands on the Dokploy host.

Dokploy version 0.29.8 and earlier contains a vulnerability due to lack of verification of destinationId ownership in backup.create, backup.update, and backup.restoreBackupWithLogs endpoints. An authenticated user with backup permissions in one organization can access another organization's S3 credentials, read backup objects, or redirect and poison backups across tenant boundaries.

Dokploy before version 0.29.13 contains a command injection vulnerability in registry credential testing and Docker Swarm cluster management endpoints, where user-controlled values are interpolated into shell commands without proper quoting. The vulnerable remote path uses execAsyncRemote, allowing arbitrary command execution on remote servers.

Dokploy before version 0.29.13 contains a command injection vulnerability in writeTraefikConfigRemote, where user-controlled Traefik configuration is interpolated into an echo command executed via execAsyncRemote. Single quotes in redirect regex, usernames, domains, or middleware configuration can break shell quoting and execute arbitrary commands on remote servers. This is an incomplete fix for CVE-2026-45630.

Dokploy before version 0.29.13 contains a command injection vulnerability in the backup.restoreBackupWithLogs subscription, where databaseName and backupFile fields are interpolated into database restore commands without proper separation from shell syntax. An authenticated user with backup-restore permission can inject operating system commands executed in the Dokploy host context.

A critical path traversal vulnerability in Dokploy 0.26.5 and earlier. Authenticated users can write arbitrary files during deployment, which combined with remote server feature enables remote code execution and full server compromise.

Dokploy in version 0.26.6 and earlier has a command injection vulnerability in the /docker-container-logs WebSocket endpoint. The tail and since parameters are not validated and are directly concatenated into shell commands, allowing authenticated users to execute arbitrary commands with root privileges.

Dokploy in 0.26.7 and earlier does not enforce organization/role checks in the schedule router. Any authenticated user can create, update, run, or delete schedules of other organizations if they know the scheduleId/serverId. Schedule types server and dokploy-server enable code execution on the host or remote server (RCE).

Dokploy versions 0.27.0 through 0.29.3 contain a hardcoded BETTER_AUTH_SECRET fallback ("better-auth-secret-123456789"), allowing an unauthenticated attacker to forge email verification JWTs, trigger auto-sign-in as admin, and execute commands on the host via the built-in SSH terminal.

Dokploy 0.28.8 and earlier contains an authenticated OS command injection vulnerability in the application.updateTraefikConfig tRPC endpoint. Admin/owner users can execute arbitrary system commands on remote servers via unsanitized echo shell interpolation.

Dokploy 0.28.8 and earlier contains an authenticated OS command injection vulnerability in the /listen-deployment WebSocket endpoint. Any organization member can execute arbitrary system commands on remote servers managed by Dokploy, leading to full server compromise.

Dokploy, a self-hosted PaaS, in version 0.29.2 and earlier constructs shell commands using JavaScript template literals and executes them via child_process.exec() without proper escaping of user input.

In Dokploy version 0.29.1 and earlier, a command injection vulnerability exists in the Docker file upload functionality. The destinationPath parameter is not properly sanitized and is directly interpolated into a shell command, allowing an authenticated user to execute arbitrary OS commands on the Dokploy host.

Dokploy version 0.26.6 and below has an OS command injection vulnerability through the appName parameter due to inadequate input sanitization and shell interpolation.

Dokploy is a free, self-hostable PaaS. Prior to 0.29.6, the user update procedure does not delete other session rows after a password change, allowing a compromised session token to remain valid for up to three days. This is fixed in version 0.29.6.

Dokploy prior to 0.29.6 allows a user with member:create permission to invite an account with the owner role, and a privileged self-hosted user can create an account with an arbitrary role, enabling permanent organization takeover because owner roles cannot be demoted.

Dokploy is a free, self-hostable Platform as a Service (PaaS). Prior to 0.29.13, dockerContextPath accepted by apps/dokploy/components/dashboard/application/build/show.tsx flows through getDockerContextPath in packages/server/src/utils/filesystem/directory.ts into the unquoted cd command in packages/server/src/utils/builders/docker-file.ts before execution by execAsync, allowing an authenticated application editor to execute arbitrary commands on the Dokploy host. This issue is fixed in version 0.29.13.

In Dokploy prior to 0.29.13, sanitizeCommand in compose.ts only trims whitespace and strips surrounding quotes from compose.command before exportEnvCommand and docker command interpolation, allowing an authenticated user who can update a Compose service to inject shell metacharacters and execute arbitrary commands on the Dokploy host. This issue is fixed in version 0.29.13.

In Dokploy prior to 0.29.13, the WebSocket handlers validate organization membership but do not enforce checkServiceAccess, accessedServerIds, or accessedServices, allowing an authenticated organization member to obtain root terminal access and read logs or statistics for restricted servers and services. This issue is fixed in version 0.29.13.

Dokploy is a free, self-hostable Platform as a Service (PaaS). Prior to 0.29.13, database backup and restore command builders in packages/server/src/utils/backups/utils.ts and packages/server/src/utils/restore/utils.ts interpolate database names, usernames, and passwords into nested shell command strings passed to child_process.exec(). An authenticated administrator with permission to create databases and configure backups can use crafted database configuration fields to execute arbitrary commands inside PostgreSQL, MariaDB, MySQL, MongoDB, or LibSQL containers, exposing database data and credentials and potentially enabling escape when a container is overprivileged. This issue is fixed in version 0.29.13.

Dokploy prior to 0.29.13 contains a command injection vulnerability in settings.readTraefikFile. A user with traefikFiles.read permission can execute arbitrary commands on a managed server via shell metacharacters in the configPath.

Dokploy prior to 0.29.13 contains a command injection vulnerability in cloneGitRepository. An authenticated user with application access can execute arbitrary OS commands on the Dokploy host by setting a malicious custom Git URL and triggering deployment.

Dokploy is a free, self-hostable Platform as a Service (PaaS). Prior to 0.29.13, application.one in apps/dokploy/server/api/routers/application.ts returns provider relations loaded by findApplicationById in packages/server/src/services/application.ts without redacting githubClientSecret, githubPrivateKey, or githubWebhookSecret, allowing a user with only service:read permission to retrieve another user’s Git provider secrets even when hasGitProviderAccess is false and unauthorizedProvider is set. This issue is fixed in version 0.29.13.

Dokploy prior to 0.29.13 contains a vulnerability in the unauthenticated /api/providers/github/setup route that trusts gh_init organizationId and userId values from the state parameter and calls createGithub, allowing an attacker to insert a GitHub App provider containing client_secret, webhook_secret, and PEM private key material into another organization.

Dokploy before version 0.29.13 contains a command injection vulnerability in the buildRemoteDocker() function, where the dockerImage value is directly interpolated into a docker pull shell command. An authenticated user with project access can execute arbitrary OS commands on the Dokploy server.

Dokploy before version 0.29.13 has a vulnerability in the WebSocket handler, where session validation does not authorize access to the requested server. An authenticated user can connect to a terminal on the Dokploy host without the required organization role or server-access check.

Dokploy prior to 0.29.13 contains a vulnerability in the createCommand() function that constructs shell commands by interpolating compose service names and configuration into bash command strings. When a compose with a maliciously crafted name or service definition is deployed, shell metacharacters are interpreted as command separators, allowing arbitrary command execution on the Docker host.

Dokploy from version 0.28.7 to 0.29.13 has a vulnerability in the server.remove tRPC mutation, which does not verify that the server's organization ID matches the session's active organization. An authenticated owner or administrator with server:delete in one organization can delete another organization's server and deployment records and receive the associated plaintext SSH private key.

In Dokploy version 0.19.0 and earlier, the protectedProcedure middleware only verifies user authentication but does not enforce organization scoping. Each endpoint must individually verify that the resource belongs to the user's organization. This affects multiple endpoints in various files.

In Dokploy version 0.29.0 and earlier, the deleteRegistry function executes docker logout without proper shell escaping of the registryUrl argument, allowing command injection. Unlike the docker login function which uses shEscape(), the lack of sanitization in deleteRegistry creates a vulnerability through a crafted registry URL.