CVE-2026-72864

The CVSS 9.9 rating is technically defensible but analytically lazy — it treats this as one user's privilege escalation when this is actually a complete trust model collapse in self-hosted Dokploy deployments. The vulnerability allows any authenticated member to obtain root shells in arbitrary containers on the Docker host, which in a multi-tenant PaaS context means one organization's user can target containers belonging to other organizations sharing the same infrastructure. The word 'arbitrary' does critical work here: if an attacker in Organization A can reach containers owned by Organization B, this isn't a privilege escalation bug — it's multi-tenant isolation failure at the architectural layer. The root cause is a convenience feature (the WebSocket terminal) built without a multi-tenant threat model. The authentication layer validates identity but performs no organizational boundary check before passing attacker-controlled container IDs to `docker exec`. This mirrors a well-documented pattern in self-hosted tooling: developer ergonomics features (terminals, debugging interfaces) get authentication bolted on, but authorization assumes single-tenant deployment or trust within an organization. CVE-2016-5728 in Jenkins and CVE-2018-1000112 in GitLab followed the same trajectory. In default (non-rootless) Docker configurations, root shell access to arbitrary containers on a shared host effectively means docker.sock-level access — one compromised tenant can escape container isolation entirely and reach host root. For operators running multi-tenant Dokploy instances, the blast radius isn't one organization's data at risk; it's every organization on that host. The fix in version 0.29.13 must be examined carefully. The critical question is whether it adds organization-scoped filtering at the container lookup layer (querying containers only within the authenticated user's organizationId) or merely adds role checks that still permit cross-tenant access within the same organization. The former closes the multi-tenant gap; the latter leaves it latent until a second organization is provisioned. If the historical pattern holds, this will be a surface patch addressing the symptom for single-org deployments while leaving multi-tenant operators exposed. Exploitability through the normal UI versus direct WebSocket manipulation matters for threat modeling but should not reduce urgency. If the endpoint exists over a documented protocol, any authenticated actor with basic tooling awareness can reach it. The more concerning dimension is operational: the WebSocket terminal endpoint (`/docker-container-terminal`) is a dark path — it lacks the HTTP routing fingerprints that automated scanners target, and many self-hosted operators may not even know this endpoint exists in their deployment. Remediation urgency is non-negotiable for multi-tenant operators. Assume cross-tenant container access occurred during the vulnerable window. The real question is whether Dokploy's architecture can support multi-tenant isolation as a first-class concern rather than a security patch — if your instance ever served more than one organization, you need to audit what other dark paths may still exist.

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