Description

Dokploy is a free, self-hostable Platform as a Service (PaaS). Prior to 0.29.13, Dokploy's WebSocket handlers (in-app terminals and log streamers) authenticate the session but never authorize it. They establish who the user is via validateRequest() and then proceed without consulting the role/permission model that every tRPC procedure enforces. Any authenticated member, can therefore open an interactive shell into any container on the host, including the dokploy container that mounts the Docker socket, and from there obtain root on the host, escaping the application and crossing every tenant boundary. This vulnerability is fixed in 0.29.13.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.9",
  "pubDate": "2026-08-10T19:17:34.870Z",
  "pubdate": "2026-08-10T19:17:34.870Z",
  "executiveSummary": "An authorization bypass vulnerability exists in Dokploy prior to version 0.29.13 within its WebSocket handlers, specifically affecting in-app terminals and log streamers.\nThe vulnerability stems from a failure to enforce the application's role and permission model after successfully authenticating sessions via validateRequest().\nAny authenticated member can exploit this flaw to establish interactive shells into arbitrary containers running on the host system, including the core dokploy container which mounts the Docker socket.\nSuccessful exploitation allows attackers to achieve container breakout, cross tenant boundaries, and obtain root privileges on the underlying host.\nThe risk implication is critical, as low-privileged authenticated users can completely compromise the entire deployment infrastructure and all managed tenants.\nThe issue is fully resolved in version 0.29.13 by properly applying the authorization checks enforced in standard tRPC procedures to all WebSocket endpoints.",
  "technicalDetails": "The root cause of the vulnerability lies in the architectural discrepancy between standard tRPC procedures and WebSocket handlers within Dokploy.\nWhile standard tRPC procedures correctly evaluate the role and permission model for incoming requests, the WebSocket handlers (used for in-app terminals and log streamers) execute validateRequest() solely for session authentication.\nFollowing authentication, the WebSocket handlers omit any secondary validation against the authorization matrix, trusting any established connection regardless of the user's assigned role or tenant boundaries.\nThe vulnerable components include the WebSocket handling logic responsible for establishing in-app terminals and log streaming sessions.\nAffected software versions include all Dokploy installations prior to version 0.29.13.\nThe exploitation requirement is authenticated access, meaning an attacker must possess valid user credentials within the Dokploy platform, though no administrative privileges are required.\nThe attack flow proceeds as follows: First, an authenticated attacker initiates a WebSocket connection to the terminal or log streaming handler. Second, the handler validates the request session using validateRequest() without verifying user permissions. Third, the attacker requests an interactive shell session targeting a specific container ID, such as the dokploy container itself. Fourth, because the dokploy container mounts the Docker socket, the attacker gains direct control over the Docker daemon from within the container context. Finally, the attacker executes container escape techniques to obtain root-level code execution on the underlying host operating system.\nPost-exploitation impact includes full system compromise, cross-tenant data access, manipulation of all managed containers, and complete host takeover."
}