The Backup Permission Became Root

EVIDENCE — CERT/CC disclosed VU#280377 on 17 September 2026 after confirming OS command injection in Dokploy's database backup and restoration paths. The vulnerable code interpolated user-controlled database names, credentials, and backup-file values into shell command strings. An authenticated account with permission to perform backups—a permission CERT/CC says is granted by default for database services—could insert shell metacharacters and obtain arbitrary command execution. Because Dokploy runs with root privileges by default, the result can be full control of the host. CERT/CC confirmed the issue in versions 0.29.8 and 0.29.11 and in canary commit 24b02f5; version 0.29.13 and later contain the fix.

BACKUP PERMISSION WAS EFFECTIVELY HOST ADMINISTRATION — The vulnerable action looks narrower than it is. A database operator is expected to create and restore backups, not control the platform server. But Dokploy manages containers, deployment credentials, repositories, databases, and other tenants from that host. CERT/CC says successful exploitation can provide persistent filesystem access and expose credentials belonging to other tenants on the same instance. The trust failure is therefore both vertical and horizontal: a lower-privilege application role can cross into root, then cross from its own database into every workload the host can reach.

TWO SHELLS MADE SIMPLE QUOTING INSUFFICIENT — Dokploy's fix explains that the generated command passed through an outer host shell and an inner shell launched by docker exec. Values placed inside the outer shell's double quotes could still expand command substitutions, backticks, and variables before inner quoting applied. The patch moves user-controlled values into escaped environment-variable assignments and references them as variables inside a single-quoted inner script. Regression tests exercise payloads against both shell layers. This is the durable lesson for deployment tooling: when strings cross shell, container, and remote-execution boundaries, each parser gets a chance to reinterpret data as code.

THE PATCH RELEASE WAS A SECURITY ROLLUP — Dokploy 0.29.13, released on 21 July, includes the backup-and-restore correction along with numerous other security fixes for Git operations, Docker build and pull commands, database deployments, registry tests, WebSocket authorization, cross-organization object access, and secret disclosure. The September CERT/CC note gives administrators a fresh reason to verify the running version rather than assuming an earlier upgrade completed. There is no public evidence in the cited sources that this backup flaw is being actively exploited, but authenticated access is the only stated prerequisite and the impact is host-level root.

WHAT TO CHECK — Identify every Dokploy server and record its running version, not merely the intended deployment tag. Upgrade anything earlier than 0.29.13 to the current supported release, then verify the service restarted on the new build. Until an upgrade is complete, remove backup and restore permissions from nonessential users and service roles. Review Dokploy authentication, tRPC, backup, restore, process, container, and outbound-network logs for unusual database names, backupFile values, shell metacharacters, command substitutions, unexpected child processes, new files, credential reads, or connections from the host. If suspicious activity appears, isolate the server, preserve disk and container evidence, rotate repository, registry, database, SSH, cloud, and deployment credentials, and rebuild affected workloads from trusted sources; patching does not remove persistence left by prior root execution.