Dokploy VU#280377 documents an authenticated command-injection path in database backup and restore operations that can cross from an application permission into host-level command execution. CERT/CC says it successfully demonstrated exploitation against Dokploy 0.29.8 and 0.29.11, as well as tested canary commit 24b02f5, and says the issue is patched in version 0.29.13 and later.
The important boundary is that this is not an unauthenticated Internet-wide compromise path. CERT/CC describes an attacker who already has a Dokploy account with relevant database backup permissions. The risk becomes severe because Dokploy normally runs with root privileges, so shell commands reached through the vulnerable path can execute with root authority on the host.
Which Dokploy versions are affected?
CERT/CC explicitly identifies Dokploy 0.29.8 and 0.29.11 as vulnerable in its testing and also reports successful exploitation against canary commit 24b02f5. The advisory says version 0.29.13 and later is patched. Operators should not interpret this as proof that every release before 0.29.13 was individually tested against every vulnerable command path; the strongest evidence is the set of versions and commit states that CERT/CC specifically names.
What permission does an attacker need?
The documented attack requires an authenticated Dokploy user who can perform database backup or restore operations. CERT/CC says backup permission is granted by default for database services, which makes role review important even when an operator believes the account has only limited application privileges.
Why can backup access become root access?
The vulnerable backup and restore flows construct shell commands using user-controlled values. If those values are not safely isolated from shell interpretation, command syntax can be injected into the host command. Because the Dokploy server process runs as root by default, successful command injection can inherit root privileges rather than remaining confined to the database operation itself.
CERT/CC warns that a successful attacker could gain full control of the Dokploy host and access credentials or workloads belonging to other tenants. The practical risk is therefore much larger than corruption of one backup job: the application-level permission boundary can become a host-level security boundary failure.
Which database services are covered?
The CERT/CC vulnerability note identifies backup and restore paths for PostgreSQL, MySQL, MariaDB, MongoDB and LibSQL. Operators using any of these database services should verify both the running Dokploy version and which users or roles hold backup permissions.
What Dokploy operators should do now
- Check the running Dokploy version. Treat explicitly affected and unpatched states as needing remediation.
- Upgrade to Dokploy 0.29.13 or later. CERT/CC identifies this as the patched release line, and Dokploy’s release notes include the database backup/restore command-injection fix among the security changes.
- Review database backup permissions. Identify every user or role that can create or restore backups and remove access that is not operationally necessary.
- If immediate upgrading is not possible, restrict backup permissions. CERT/CC recommends disabling the default backup permission and granting it only to users or roles that require it.
- Monitor for updated guidance. Recheck CERT/CC and Dokploy if the affected-version scope, advisory mapping, exploitation status or mitigation guidance changes.
Do not confuse VU#280377 with every earlier Dokploy command-injection advisory
Dokploy released a broad security-hardening update in version 0.29.13 that addressed multiple command-injection and authorization problems. Some earlier GitHub Security Advisories describe related but separately scoped vulnerabilities, including command injection through particular database parameters. Those advisories provide useful technical context, but TPS did not find evidence that one earlier CVE identifier should automatically be treated as the identifier for the entire CERT/CC VU#280377 disclosure.
Is active exploitation confirmed?
TPS did not find authoritative evidence in the reviewed sources showing exploitation of VU#280377 in the wild. CERT/CC’s statement that it successfully exploited affected versions refers to vulnerability testing and proof of exploitability, not evidence that attackers are currently exploiting Internet-facing Dokploy systems.
What remains unknown
The reviewed evidence does not establish a complete prevalence count for vulnerable Dokploy deployments, a definitive CVE mapping covering the entire VU#280377 disclosure, or whether every release before 0.29.13 is affected by every specific command-injection sink described by CERT/CC. Those boundaries should remain explicit rather than being inferred from the fixed-release number alone.
Verification note
TPS reconciled the September 17 CERT/CC vulnerability note with Dokploy’s official 0.29.13 release information and related Dokploy GitHub security advisories. The resulting guidance preserves the authentication and permission prerequisites, the explicitly tested vulnerable states, the documented fixed release and the distinction between VU#280377 and earlier separately scoped Dokploy advisories.