CVE-2026-86059
CriticalCVSS 9.6Summary
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.
Risk Assessment
A member with application read access or a provider identifier can bypass per-member provider assignment and use the exposed credentials to access private repositories or manipulate external workflows.
Recommendation
Update Dokploy to version 0.29.13 or later, then revoke and rotate all exposed Git provider credentials.
Other vulnerabilities in Dokploy
See all- 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.
- CVE-2026-72877Critical
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.
- CVE-2026-72876Critical
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.
Original NVD description (English source)
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. A member with application read access or a provider identifier can therefore bypass per-member provider assignment and use the exposed credentials to access private repositories or manipulate external workflows. This issue is fixed in version 0.29.13.

