Act nowDisclosed

Advisory · CVE-2026-129433

Dokploy backup flaw lets any member run commands as root

Dokploy before 0.31.1 interpolates the backup serviceName directly into a shell command, so an authenticated organization member can execute commands as root and take over the host through the mounted Docker socket.

Advisory published November 14, 2026Independent summary
Vendor
Dokploy
Product
Dokploy
Identifier / CWE
CVE-2026-129433
CWE-78
Action timing
Immediate
ELI5

Explain it like I’m five

Dokploy lets team members set up backups for their apps. One of the backup settings, the service name, is pasted straight into a shell command without checking it first. A regular team member can hide a command inside that name, and Dokploy runs it as root every minute. Because Dokploy can talk to Docker, that means full control of the whole server.

SIMPLIFIED_ATTACK_PATH05 STEPS
  1. 01Member access

    An authenticated organization member with access to a single project signs in. No admin or owner role is needed.

  2. 02Poisoned backup

    The member creates or updates a compose backup, putting shell metacharacters in the serviceName field. The value is accepted without validation.

  3. 03Command built unsafely

    When the backup runs, getComposeContainerCommand() interpolates serviceName directly into a shell command string executed with /bin/bash.

  4. 04Root execution

    The scheduled backup fires, by default every minute, and the injected command runs as root inside the Dokploy container.

  5. 05Host takeover

    Standard Dokploy installations mount the Docker socket, so root inside the container becomes full control of the host and everything Dokploy manages.

What happened

Dokploy before 0.31.1 contains an OS command injection vulnerability in getComposeContainerCommand(). The serviceName field accepted by the backup.create and backup.update procedures is interpolated directly into a shell command string without sanitization or escaping, and the backup command is executed with /bin/bash. The GitHub security advisory rates the issue critical at CVSS 9.9.

Exploitation requires only a member-level account. A member with access to a single project can create a backup with an injected serviceName targeting any destination already registered in the organization. The injected command executes as root inside the Dokploy container at the next scheduled backup run, by default every minute. Because standard Dokploy installations mount /var/run/docker.sock, this leads to full host compromise.

Dokploy 0.31.1 fixes the issue. Releases before 0.31.1 are affected.

What to do

  1. Upgrade Dokploy to 0.31.1 or later using the project release guidance.
  2. Audit organization members and recent backup.create and backup.update activity for unusual or suspicious serviceName values.
  3. Review backup job logs and container activity for unexpected shell commands, outbound connections, or new containers and images.
  4. Check whether the Docker socket was used to create, modify, or inspect containers outside normal deployments.
  5. Determine which deployment keys, database credentials, and environment secrets were reachable from the Dokploy server.
  6. Rotate credentials if unauthorized backup activity or other suspicious commands cannot be excluded.
  7. Verify the deployed version after the update and confirm backup jobs run cleanly.

Management note

This is a privilege-boundary failure, not just a patching task: any member account, not only admins, could become host root. Treat the upgrade as urgent, and pair it with an audit of who holds member access and what backup activity ran before the fix. Self-hosted deployment platforms concentrate keys and credentials, so a compromise here reaches every application Dokploy manages.