The CVSS 9.9 rating undersells this vulnerability because the actual flaw is architectural, not merely a missing check. Dokploy's permission model treats serverId as an implicit authorization boundary when it functions only as an opaque handle—any caller with server:read on their own organization can query any serverId from any tenant through four endpoints (deploy, restart, stop, getNodeInfo) that lack an activeOrganizationId ownership assertion. The enumeration isn't theoretical: serverId values leak through operational side channels in PaaS environments—webhook URLs in repos, DNS records, Docker contexts, log aggregation endpoints—making cross-tenant harvesting trivial regardless of whether identifiers are cryptographically random.
The command injection in getNodeInfo compounds this by passing the enumerated nodeId directly to execAsyncRemote without validation. The injection point and the authorization gap are the same failure: upstream context validation is absent, allowing untrusted input to reach a sensitive sink.
What makes this severe is the multiplier effect. Four endpoints sharing this pattern isn't four vulnerabilities—it's evidence of a class. This exact failure mode has appeared across every generation of PaaS platforms: Cloud Foundry (2015), Heroku (2018), Kubernetes RBAC (2019). The historical pattern suggests you're looking at the leading edge, not the totality. A targeted patch to the four known endpoints is incident response, not decontamination. The underlying assumption—that resource identifiers carry organizational context—almost certainly exists elsewhere in the API surface.
Remediation should be two-layered. First, deploy the 0.29.13 patch for the confirmed endpoints. Second, implement a systematic audit: grep your tRPC router for any handler accepting serverId, nodeId, projectId, or applicationId as a top-level input without a paired organizationId parameter in the same signature. This pattern is grep tractable in Dokploy's router structure. Consider reclassifying server:read as a higher-privilege scope given its cross-tenant implications, or restructuring serverId as an opaque capability requiring explicit delegation. The static analysis rule should become permanent—treat any resourceId accepted without organizational context as a finding.