Dokploy's CVE-2026-72868 has a 9.9 CVSS score, and the remediation will focus on the command injection in the rclone execution path. That's the wrong frame. The vulnerability isn't just that user input reached child_process.exec — it's that the authorization gate was never designed to guard that operation in the first place. The withPermission('destination', 'create') check enforces organizational boundaries (preventing cross-organization access), but it was never designed to answer whether a user should be trusted to execute arbitrary system commands. Those are fundamentally different security questions, and treating one as a proxy for the other is the architectural failure that produced this CVE.
The destination.testConnection mutation accepts user-controlled rclone arguments, executes them as root inside the Dokploy container, and that container holds the host Docker socket. This creates a three-stage cascade: low-privilege GraphQL user → root-equivalent process in Dokploy container → host compromise via Docker socket. The CVSS captures the blast radius, but it masks the real problem — the trust boundary between 'can create a storage destination' and 'can execute rclone commands as root' was never defined. The permission check succeeded at what it was designed to do (organizational isolation) and failed at what it was incorrectly presumed to do (operation safety).
When patching, ask whether 0.29.13 addressed the symptom or the structure. Input sanitization and command parameterization close this specific vector, but they leave the underlying pattern intact: other mutations gated only by resource-level permissions that perform privileged operations with unsanitized input. The fix that actually hardens the system is a new permission scope for privileged operations, distinct from resource-scoped permissions — but that requires admitting the existing abstraction was insufficient, which most projects resist until forced.
The Docker socket access compounds everything. For a self-hosted PaaS, container management inherently requires Docker access, so this isn't a misconfiguration — it's architectural. The question is whether Dokploy's threat model defines what happens when the Dokploy container itself is compromised. If it wasn't, the 9.9 score measures an unacknowledged blast radius rather than a patched hole. Verify whether 0.29.13 included architectural hardening beyond the input-validation fix, or whether it closed one vector while leaving the blast radius unchanged.