GPU VulnDB

Database/Container, Kubernetes & orchestration

Dokploy: shell injection through backup serviceName runs commands as root on the host via the Docker socket

CVSS 9.4CVE-2026-129433Container, Kubernetes & orchestrationcurated

Impact

Dokploy stores the serviceName given to the backup.create and backup.update tRPC procedures and later puts it, unescaped, into a shell command in getComposeContainerCommand(). Any authenticated organization member can store a value containing shell metacharacters, and it runs as root the next time the scheduled backup fires. Dokploy has the Docker socket mounted, so this means full control of the host: every container on it, every tenant's volumes and secrets, and the host filesystem. The payload sits in a stored backup definition, so it runs again on every backup cycle until someone removes it.

Who can reach it

Network access to the Dokploy API with any authenticated organization member account that can create or update a backup. No admin role is needed. The payload runs later on the backup schedule, with no further action from the attacker.

What to do

Upgrade to Dokploy 0.31.1 (fix in commit b24006e, PR 5908) and restart the Dokploy stack, which interrupts in-flight deploys. Stored backup definitions are not cleaned up by the upgrade, so check existing backup serviceName values for shell metacharacters. Given root-on-host impact on a shared instance, rotate host-reachable secrets if any member account is untrusted. No workaround is published.

References

Related entries

All Container, Kubernetes & orchestration entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.