CVE-2026-72866: Dokploy Auth Bypass Vulnerability

CVE-2026-72866 Overview

CVE-2026-72866 is a missing authorization vulnerability [CWE-862] in Dokploy, a free, self-hostable Platform as a Service (PaaS). Versions prior to 0.29.13 contain a flawed WebSocket handler in apps/dokploy/server/wss/terminal.ts that validates a user session but never authorizes access to the requested server. An authenticated user can connect to /terminal?serverId=local and obtain an interactive terminal on the Dokploy host. The handler grants access without checking for an organization role or server-access permission. The issue is fixed in version 0.29.13.

Critical Impact
Any authenticated Dokploy user can obtain an interactive root-context shell on the Dokploy host, leading to full compromise of the PaaS control plane and hosted workloads.

Affected Products

Dokploy versions prior to 0.29.13
Component: apps/dokploy/server/wss/terminal.ts WebSocket handler
Related handlers: docker-container-logs.ts, docker-container-terminal.ts

Discovery Timeline

2026-08-10 - CVE-2026-72866 published to NVD
2026-08-10 - Last updated in NVD database

Technical Details for CVE-2026-72866

Vulnerability Analysis

Dokploy exposes WebSocket endpoints that back its in-browser terminal and container inspection tooling. The terminal.ts handler accepts a serverId query parameter and, when the special value local is supplied, spawns an interactive shell on the Dokploy host itself. Before the fix, the handler only checked that the caller had a valid session and belonged to some organization. It did not verify that the caller held a role that permits Docker or server access, nor that the requested server was one the caller was authorized to reach.

Because the terminal runs in the context of the Dokploy service on the host, an attacker who lands a shell can read secrets, modify deployments, and pivot to any container or remote server Dokploy manages. The same authorization gap affected the container logs and container terminal WebSocket handlers.

Root Cause

The root cause is missing authorization [CWE-862] at the WebSocket layer. Session validation was conflated with access control. The handler assumed that membership in an organization implied entitlement to every serverId, including the sentinel local value that maps to the host. No permission predicate such as hasPermission(ctx, { docker: ["read"] }) or accessible-server lookup was invoked before wiring the client socket to a PTY.

Attack Vector

An attacker with any authenticated Dokploy account, including a low-privilege member, opens a WebSocket to /terminal?serverId=local. The server accepts the connection, spawns a shell via node-pty, and streams stdin/stdout back to the attacker. No organization role check, canAccessToDocker check, or server-access check gates the connection.

typescript

// Patch introducing centralized authorization for WebSocket handlers
// Source: https://github.com/Dokploy/dokploy/commit/68f5afae42fca353dcb3d3bc6219ffe9e168cb91

import { getAccessibleServerIds } from "@dokploy/server";
import {
	findMemberByUserId,
	hasPermission,
} from "@dokploy/server/services/permission";

type WssUser = { id: string } | null | undefined;
type WssSession = { activeOrganizationId?: string | null } | null | undefined;

const buildCtx = (user: { id: string }, activeOrganizationId: string) => ({
	user: { id: user.id },
	session: { activeOrganizationId },
});

// Authorizes docker/container operations opened over a WebSocket (container
// terminal, container logs, container stats). Requires the docker permission
// (owner/admin, or a member explicitly granted canAccessToDocker) and, for a
// remote server, that the server is accessible to the caller. Previously these
// handlers only checked session + organization, so any member could reach a
// root shell / logs of any container.
export const canAccessDockerOverWss = async (
	user: WssUser,
	session: WssSession,
	serverId?: string | null,
): Promise<boolean> => {
	if (!user || !session?.activeOrganizationId) return false;

	const ctx = buildCtx(user, session.activeOrganizationId);
	if (!(await hasPermission(ctx, { docker: ["read"] }))) return false;

The companion patch wires the new authorizer into the affected handlers:

typescript

// apps/dokploy/server/wss/docker-container-logs.ts
// Source: https://github.com/Dokploy/dokploy/commit/68f5afae42fca353dcb3d3bc6219ffe9e168cb91

import { spawn } from "node-pty";
import { Client } from "ssh2";
import { WebSocketServer } from "ws";
import { canAccessDockerOverWss } from "./authorize";
import {
	getShell,
	isValidContainerId,

Detection Methods for CVE-2026-72866

Indicators of Compromise

WebSocket upgrade requests to /terminal?serverId=local originating from user accounts that do not hold owner or admin roles.
Unexpected node-pty child processes spawned by the Dokploy service, particularly sh or bash sessions with no corresponding scheduled deployment.
Outbound egress from the Dokploy host to attacker-controlled infrastructure shortly after a low-privilege user session.
New or modified files under Dokploy configuration, secret, or SSH key directories following a member-level login.

Detection Strategies

Inspect Dokploy access and application logs for WebSocket connections to terminal and docker-container endpoints correlated with the serverId=local parameter.
Alert on shell process creation (sh, bash, /bin/*) parented by the Dokploy Node.js process outside of expected deploy workflows.
Cross-reference authenticated user IDs with organization role assignments and flag terminal usage by non-admin members.

Monitoring Recommendations

Enable verbose logging on the reverse proxy in front of Dokploy to capture WebSocket upgrade paths and query strings.
Monitor the Dokploy host for anomalous outbound connections, credential file reads, and modifications to /root/.ssh/.
Track version drift of the Dokploy container or binary and alert when instances remain below 0.29.13.

How to Mitigate CVE-2026-72866

Immediate Actions Required

Upgrade Dokploy to version 0.29.13 or later on every self-hosted instance.
Audit organization membership and remove accounts that do not require access to the Dokploy control plane.
Rotate secrets, API tokens, and SSH keys stored on or accessible from the Dokploy host if pre-patch access by untrusted members cannot be ruled out.
Review deployment, container, and server logs for unauthorized terminal sessions predating the upgrade.

Patch Information

The fix is included in Dokploy release v0.29.13. The patch adds a canAccessDockerOverWss authorizer in apps/dokploy/server/wss/authorize.ts that requires the docker:read permission and, for remote servers, verifies the target serverId is in the caller's accessible server set. See the GitHub commit, the pull request discussion, and the GHSA-c68r-7wg9-p7v2 advisory for implementation details.

Workarounds

Restrict network access to the Dokploy web interface using a VPN, IP allowlist, or authenticating reverse proxy until the upgrade is applied.
Temporarily reduce all non-essential accounts to no organization membership, since any authenticated member can reach the vulnerable handler.
Terminate active WebSocket sessions and force re-authentication after applying the patch.

bash

# Upgrade a self-hosted Dokploy instance to the fixed release
docker pull dokploy/dokploy:0.29.13
docker stop dokploy && docker rm dokploy
# Recreate the container using your existing volumes and environment
# Then verify the running version
curl -s http://localhost:3000/api/health | grep -i version