CVE-2026-72863

Dokploy versions before 0.29.13 contain a WebSocket authorization bypass that allows any authenticated user to execute privileged operations — specifically, accessing terminal sessions and container management across all tenants on a host. The vulnerability isn't a misconfigured permission check; it's a structural failure where the WebSocket handlers implement authentication (via validateRequest()) but never invoke the role-based authorization model that every tRPC procedure in the application enforces. The root cause is architectural: tRPC procedures have inline authorization checks that are visible at the call site, making them hard to miss during review. The WebSocket handlers, added later to support real-time terminal streams, received authentication wiring but exist in a separate code path with no reference to the permission layer. Someone reading the WebSocket handler code would see validateRequest() and have no reason to think anything is missing — the authorization model simply doesn't exist in that scope. This is the same topology that produced past WebSocket authorization bypasses in Polycom cameras, Hadoop, and elsewhere. The pattern recurs because developers implementing real-time features think about connection persistence and message framing; access control feels like something the surrounding infrastructure handles. The blast radius compounds the technical failure. Dokploy containers mount the Docker socket to manage containers — that's the product's core function, not an incidental risk choice. Compromising the authorization gap doesn't just give you unauthorized feature access; it gives you exec capability on the management container, which means access to the Docker socket and thus control over every tenant on the host. CVSS 9.9 captures severity, but the cross-tenant escalation is structural to the architecture, not a consequence of poor socket hygiene. If you run Dokploy: upgrade to 0.29.13 or later immediately. There's no forced update mechanism for self-hosted deployments — the CVE is published, but your instance remains vulnerable until you apply the patch manually. Check your running version now. Beyond patching, audit any other real-time or WebSocket code paths for the same pattern: authentication without authorization isn't just a bug in the handler you found, it's a signal that the codebase may have evolved two separate security paradigms with no shared surface. The fix closed the vulnerability; the architectural condition that produced it — parallel execution paths with inconsistent security models — needs structural attention to prevent recurrence.

Reviewed through automated stages and approved by a human before publication.