CVE-2026-43917
MediumCVSS 5.3Exploitation Probability (EPSS)
Low risk13th percentile - higher than 13% of all known CVEs
Summary
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.
Risk Assessment
Lack of organization scoping enforcement could allow an authenticated user to access resources of other organizations, leading to data isolation breaches.
Recommendation
Update Dokploy to a version above 0.19.0 if available, or manually add organization scoping verification to each endpoint.
Other vulnerabilities in Dokploy
See all- 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.
- CVE-2026-72872Critical
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.
Original NVD description (English source)
Dokploy is a free, self-hostable Platform as a Service (PaaS). In 0.19.0 and earlier, the protectedProcedure middleware only verifies the user is authenticated - it does NOT enforce organization scoping. Each endpoint must individually verify the resource's org matches the session's activeOrganizationId. This affects the following endpoints: allByType, killProcess, and removeDeployment in deployment.ts; delete in rollbacks.ts; create, one, update, remove, manualBackupPostgres, MySql, Mariadb, Mongo, Compose, WebServer, and listBackupFiles in backup.ts; list, one, delete, update, runManually, and restoreVolumeBackupWithLogs in volume-backups.ts; getNodes, removeWorker, addWorker, and addManager in cluster.ts; and create in mount.ts.

