CVE-2026-72886 in Dokploy is a member-to-root privilege escalation through authorization bypass. A member-level user can execute arbitrary scripts on the host by exploiting a gap in how the scheduler handles service identification.
The vulnerability lives in the conditional logic that derives serviceId from either applicationId or composeId. An authorization gate exists in the codebase for host-level scheduling — the developers were not unaware of the requirement. But the gate was placed in only one branch of the conditional. When a valid applicationId is supplied by a legitimate member user, the code path bypasses the host-level authorization check entirely, allowing arbitrary command execution as root.
This is not a missing authorization — it is misapplied authorization. The gate exists, but the conditional derivation of serviceId created a second code path that was never gated. The pattern is well-documented in security literature: authorization placed downstream of conditional identifier derivation produces gaps that are invisible during normal development because each branch is reasoned about in isolation.
For defenders, the priority actions are: first, verify your Dokploy instance is on version 0.29.13 or later. Second, audit any custom scheduling logic you have added — if it derives service identifiers conditionally and routes through shared functions, check that every reachable path passes through the same authorization gate. Third, examine whether your deployment topology creates blast radius exposure: a compromised member account on a self-hosted Dokploy instance with root scheduling access can pivot to every database, application, and credential that instance manages.
The deeper concern is structural. The fix — whether it moved the gate to a common code path or simply duplicated it in the missing branch — determines whether this vulnerability class will recur. If the dual-source derivation of serviceId remains, a future developer adding a third source (a new service type, for example) will face the same forgetting. The durable fix requires eliminating the conditional derivation entirely and requiring a single authoritative source for service identification at the type level. That is a refactor, not a patch, and it is the only approach that addresses the pattern rather than this instance.