Dokploy: 35 CVEs expose deployment control-plane risk

On 10 August 2026, vulnerability databases published 35 CVE records affecting Dokploy, a self-hosted platform for deploying applications and databases to servers and Docker Swarm clusters. The set includes operating-system command injection, broken organisation boundaries, unsafe path handling and missing authorization around administrative functions. Many entries carry a CVSS 3.1 score of 9.9, but this is not one anonymous exploit that works against every installation. Individual flaws have different preconditions and often require a low-privileged account or access to a particular project.

The main operational message is simpler: administrators should establish whether they run at least version 0.29.13, whose release bundles the relevant security changes. The later CVE publication date does not mean teams have to wait for another package. Here, fixes preceded coordinated disclosure. Organisations still need to verify the artifact actually running, panel exposure, user accounts and any signs of misuse before the update.

What the 35-CVE set actually contains

Dokploy is a control plane. It receives credentials for registries and Git providers, creates Docker and Traefik configuration, runs backup jobs, manages WebSocket terminals and schedules deployments. A flaw therefore has a larger blast radius than one in an ordinary content panel. The process may be able to launch containers, write configuration, call cloud APIs and read deployment secrets.

Records such as CVE-2026-72733 describe command injection in backup and restore flows. Others cover repository cloning across Git providers, Traefik generation, image names or Docker Compose paths. CVE-2026-72863 is among the authorization-boundary cases, while further records concern terminals, schedules, certificates, registries and Swarm functions. The full list is useful as a remediation inventory, but the number alone does not explain the risk architecture.

There are two recurring patterns. First, user-controlled values reached operations with system effects without a strong separation between data and commands. Second, not every procedure consistently verified whether a user in one organisation was allowed to act on the referenced resource. A control plane must enforce both boundaries: the syntactic boundary between values and code, and the business boundary between tenants.

Why 9.9 does not mean “no login required”

Many records use a CVSS vector with low privileges and changed scope. That fits a case in which a normal panel user can cause code execution on a host or reach another organisation’s resources. A 9.9 score says the impact can be critical once those conditions are met; it does not say that an anonymous Internet client can always take over the panel.

That distinction changes detection. A team should not search only for failed sign-ins from unfamiliar addresses. It should review existing account activity, organisation invitations, role changes and unusual repository, branch, service, path and backup-job names. If an engineer’s account was already compromised, a valid session may have become the entry point to the vulnerable operation.

There is also no basis for calling every installation breached. Public records establish vulnerability classes and affected versions, not a universal exploitation campaign. Breachroad’s conclusion is that panel exposure and the number of untrusted low-privileged users should influence investigation priority as strongly as the version number.

What version 0.29.13 changes

The Dokploy 0.29.13 release notes list a broad security package. It includes command injection in repository cloning across providers, credential exposure through cross-organisation access flaws and stronger validation around administrative operations. Some earlier conditions had already been addressed in 0.29.8, but 0.29.13 is the practical baseline for this disclosure wave.

Do not compare the release only with a value written in a CMDB. Inspect the running container or image, its digest, the last deployment time and every replica. In an environment that pins images manually, a registry tag may have moved while an old digest keeps running. In a high-availability setup, one forgotten replica may still receive requests.

Upgrade according to the project’s instructions and after making a verified recovery copy. A control plane manages production, so an unplanned restart can interrupt jobs and deployments. The backup must not be placed in the same unprotected location or require running a vulnerable feature in a way that increases exposure. Restrict network access first, then establish a recovery point and update.

An administrator’s response plan

1. Find every Dokploy instance, including development, private and team-managed deployments missing from central inventory.
2. Read the effective version and image digest. Mark every instance older than 0.29.13 for urgent handling.
3. Restrict the panel to a VPN, identity-aware gateway or trusted management network. An obscure URL is not a control.
4. Upgrade using the documented procedure, confirm migrations and ensure every replica uses the new image.
5. Review users, roles, tokens, Git integrations, registries, schedules, backup jobs and recent configuration changes.
6. Compare running containers, networks, volumes, Traefik rules and SSH keys with the expected state.
7. If the panel was public or had many low-privileged users, rotate secrets reachable from the control plane and extend analysis to worker hosts.

Rotation may include Git tokens, registry keys, database credentials, cloud API keys, DNS credentials and application secrets. They were not necessarily all exposed, but after confirmed host-level code execution there is little basis for assuming confidentiality. Issue new values only after removing persistence, or an intruder may collect them again.

Telemetry that can preserve evidence

The most useful records sit outside Dokploy: identity-gateway events, Git provider history, registry audit logs, cloud API events, DNS logs and host telemetry. A process with write access can alter a local log, so a central copy has stronger evidential value. Look for unusual shell child processes, new SSH keys, novel outbound destinations, containers without a known deployment and changes at times that do not match team activity.

Do not build detection solely around shell metacharacters in HTTP parameters. The set spans many fields and encodings, and CVE descriptions are not a complete attack signature. A behavioural chain is stronger: an account creates or modifies a resource, after which the control plane launches an unusual process or connects to a new destination. Such logic can also catch future variants.

After upgrading, run a controlled two-tenant authorization test. A user in organisation A must not read, edit or execute a resource in organisation B even when its identifier is known. Check that name and path fields are validated on the server as well. The aim is to confirm boundaries, not reproduce a public exploit against production.

The architectural lesson

The Dokploy wave shows that a deployment platform is a privileged system even when its UI resembles a familiar SaaS dashboard. It deserves a separate network zone, strong MFA, short sessions, minimum roles, external logging and narrowly scoped secrets. The host should not automatically reach an entire organisation merely because that makes the initial setup convenient.

Teams building internal DevOps panels should take two lessons. System operations should use safe argument APIs rather than concatenated shell commands. Every procedure that receives a resource identifier must independently verify organisation membership instead of trusting a previous UI view. Negative tests for both boundaries belong in CI.

The version and vulnerability facts above come from CVE records and the project’s release. Segmentation, rotation and detection recommendations are Breachroad’s assessment based on the control plane’s role. To turn cases like this into repeatable team decisions, see our cybersecurity training for organisations. An assessment of cloud security controls can add an independent review of deployment-platform exposure and configuration.