Description

Dokploy is a free, self-hostable Platform as a Service (PaaS). From 0.29.2 until 0.29.13, schedule.create and schedule.update in apps/dokploy/server/api/routers/schedule.ts derive serviceId from applicationId or composeId and execute the owner/admin host-schedule gate only in the alternative branch, allowing a member with access to one application to attach its applicationId to a dokploy-server schedule and run a supplied script as root through schedule.runManually. This issue is fixed in version 0.29.13.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.9",
  "pubDate": "2026-08-10T20:17:35.423Z",
  "pubdate": "2026-08-10T20:17:35.423Z",
  "executiveSummary": "An authorization bypass vulnerability exists in Dokploy versions 0.29.2 through 0.29.13, specifically within the schedule management functionality of the tRPC API routers. The vulnerability arises from flawed conditional logic when deriving the serviceId from either the applicationId or composeId within schedule.create and schedule.update functions, resulting in the owner or admin host-schedule security gate executing only in the alternative branch.\nThis flaw allows an authenticated user with restricted membership access to a single application to successfully attach its applicationId to a dokploy-server schedule. Consequently, unauthorized actors can leverage the schedule.runManually function to execute arbitrary scripts with root privileges on the underlying host system.\nThe impact of this vulnerability is critical, leading to complete host system compromise, arbitrary code execution as the root user, and a failure of tenant isolation boundaries within self-hosted deployments. Exploitation requires standard user access to the platform and valid application-level permissions to target a specific application identifier.",
  "technicalDetails": "The vulnerability is localized within the file apps/dokploy/server/api/routers/schedule.ts in the Dokploy platform, affecting versions 0.29.2 to 0.29.13. The root cause stems from improper implementation of authorization checks in the schedule.create and schedule.update API endpoints.\nDuring the processing of schedule creation and update requests, the application attempts to derive the serviceId using provided parameters such as applicationId or composeId. Due to logic errors in how the branches are structured, the security gate responsible for enforcing owner or admin host-schedule privileges is executed exclusively within the alternative branch of the conditional check.\nAn attacker with low-privilege member access to a single application can exploit this design flaw by supplying an arbitrary applicationId within a schedule modification or creation payload. Because the access control check is bypassed in the primary execution branch, the operation succeeds without validating whether the user possesses administrative or owner rights over the target host resources.\nOnce the malicious or unauthorized schedule is successfully created or updated with the attacker-controlled applicationId, the attacker can invoke the schedule.runManually procedure. This action triggers the execution of the supplied script directly on the host server.\nDue to the operational context of the dokploy-server process, the script executes with root privileges, leading to complete compromise of the underlying host operating system. The vulnerability requires authenticated access to the API, but bypasses intended role-based access control (RBAC) boundaries by exploiting improper conditional evaluation in tRPC router logic."
}