CVE-2026-72863 in Dokploy
Summary
by MITRE • 08/10/2026
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/10/2026
The vulnerability in Dokploy versions prior to 0.29.13 represents a critical authorization flaw that undermines the fundamental security boundaries of the platform as a service. This issue stems from improper session handling within the WebSocket communication channels that power the application's terminal and log streaming functionalities. The core problem manifests when the system authenticates users through the validateRequest() function but fails to implement proper authorization checks before granting access to sensitive container operations. This architectural gap creates a path for privilege escalation that bypasses all standard access control mechanisms.
The technical implementation of this vulnerability exploits the mismatch between authentication and authorization phases within the WebSocket handlers. When users establish connections for in-app terminals or log streamers, the system correctly verifies their credentials through validateRequest() but then proceeds without consulting the role-based permission model that governs all other tRPC procedures throughout the application. This fundamental flaw means that any authenticated user can potentially access container resources regardless of their assigned permissions or tenant boundaries. The vulnerability becomes particularly dangerous when considering that the dokploy container has direct access to the Docker socket, creating a direct pathway for privilege escalation from container-level access to host-level root privileges.
The operational impact of this vulnerability extends far beyond typical authorization bypass scenarios, creating a complete breakdown in multi-tenant isolation and system security boundaries. An authenticated attacker can leverage this flaw to open interactive shells into any container running on the host system, including privileged containers that mount the Docker socket. This access enables attackers to execute arbitrary commands with root privileges on the underlying host machine, effectively neutralizing all containerization security measures and tenant isolation protocols. The implications are severe for shared hosting environments where multiple users or organizations rely on the platform's security boundaries to protect their applications and data.
This vulnerability maps directly to CWE-862, which describes inadequate authorization within software systems, and aligns with ATT&CK techniques related to privilege escalation and container escape. The flaw represents a classic case of insufficient authorization control where authentication is performed but authorization decisions are not properly enforced. Organizations should implement immediate mitigations including upgrading to version 0.29.13 or later, which addresses this specific authorization gap by ensuring that WebSocket handlers perform proper role-based access checks before granting container-level access. Additionally, security teams should conduct thorough audits of all WebSocket and real-time communication channels to identify similar authorization bypass vulnerabilities in their systems.
The fix implemented in version 0.29.13 demonstrates the importance of maintaining consistent security controls across all application interfaces, particularly those that handle sensitive operations or provide direct access to underlying system resources. This vulnerability serves as a reminder that WebSocket handlers and real-time communication channels require the same rigorous authorization checks as traditional API endpoints, especially when they provide access to privileged system functions or container-level operations. Organizations deploying similar PaaS solutions must ensure that all communication channels enforce proper authorization boundaries and maintain consistent security postures across their entire application architecture.