Description

Dokploy is a free, self-hostable Platform as a Service (PaaS). Prior to 0.29.13, swarm.getNodes, swarm.getNodeInfo, swarm.getNodeApps, and swarm.getAppInfos in apps/dokploy/server/api/routers/swarm.ts accept another organization’s serverId without an activeOrganizationId ownership check, and getNodeInfo in packages/server/src/services/docker.ts interpolates nodeId into execAsyncRemote, allowing a caller with server:read permission to execute arbitrary commands as the configured SSH user on another tenant’s server. This issue is fixed in version 0.29.13.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.9",
  "pubDate": "2026-08-10T20:17:33.967Z",
  "pubdate": "2026-08-10T20:17:33.967Z",
  "executiveSummary": "A cross-tenant remote command execution vulnerability exists in Dokploy prior to version 0.29.13. The vulnerability arises due to insufficient authorization checks within the swarm management API endpoints, allowing a user with minimal server:read permissions to access and manipulate infrastructure resources belonging to separate organizations.\nThe root cause spans multiple functions within apps/dokploy/server/api/routers/swarm.ts and packages/server/src/services/docker.ts, where server identifiers are accepted without validating the activeOrganizationId ownership context. Furthermore, the getNodeInfo function insecurely interpolates the node identifier directly into the execAsyncRemote execution context.\nAn authenticated attacker possessing the server:read permission can leverage this flaw to target arbitrary tenant servers, injecting and executing arbitrary system commands as the configured SSH user. This compromises multi-tenant isolation, threatens the integrity and confidentiality of peer infrastructure, and leads to full remote code execution across managed Docker swarm nodes.",
  "technicalDetails": "The vulnerability affects Dokploy prior to version 0.29.13, specifically targeting the API router logic located in apps/dokploy/server/api/routers/swarm.ts and the core service logic in packages/server/src/services/docker.ts.\nThe root cause is a lack of proper tenant isolation and input validation. Specifically, the API procedures swarm.getNodes, swarm.getNodeInfo, swarm.getNodeApps, and swarm.getAppInfos accept external server identifiers (serverId) from client requests without verifying whether the requested resource correlates to the active organization via an activeOrganizationId ownership check.\nBecause tenant ownership validation is omitted, an authenticated user belonging to one organization can query and interact with server resources owned by an entirely different tenant, provided they hold the baseline server:read permission.\nThe attack flow proceeds as follows: First, the malicious actor submits an API request to one of the vulnerable swarm endpoints specifying an unauthorized, cross-tenant serverId. The backend fails to validate the organization context and processes the request. Subsequently, the call reaches the getNodeInfo function in packages/server/src/services/docker.ts.\nWithin getNodeInfo, the provided nodeId parameter is unsafely interpolated directly into the execAsyncRemote execution utility without proper sanitization or parameterization. This behavior allows malicious input or crafted identifiers to break out of the intended argument context.\nAs a result, the attacker can achieve arbitrary command execution on the targeted remote server operating as the configured SSH user. The post-exploitation impact includes full system compromise of peer tenant infrastructure, arbitrary file manipulation, data exfiltration, and lateral movement across the containerized environment."
}