Dokploy CVE-2026: Critical Update to 0.29.13

On September 25, 2026, two security advisories were published simultaneously for Dokploy, the self-hosted deployment tool that competes with Heroku and Render. The combination of the two constitutes the most severe threat to hit the self-hosted PaaS ecosystem in 2026: no account required, root on the host in under a minute, and every instance below version 0.29.13 is exposed.

CVE-2026-45631 (CVSS 10.0) concerns a JWT secret hardcoded in the source code. CVE-2026-72863 (CVSS 9.9) concerns WebSocket handlers that authenticate without authorizing. Taken separately, each is already critical. Chained together, they form a complete attack: the first provides administrative identity, the second provides execution.

GitHub advisory GHSA-w3gm-rc4p-9rhj describes a CWE-798 vulnerability — use of hardcoded credentials. Dokploy uses the better-auth library for session and JWT token management. In versions 0.27.0 through 0.29.2 inclusive, the default value for the BETTER_AUTH_SECRET variable was left as better-auth-secret-123456789 in the publicly published source code.

This value is what signs all Dokploy administration JWT tokens. Anyone who knows it — and it has been public since the first commit of version 0.27.0 — can forge a valid JWT token with administrator rights, without holding any account on the target instance. Dokploy's admin API then accepts all requests: reading all deployment secrets, executing commands via the API, modifying service configurations.

A CVSS score of 10.0 is the absolute maximum. It reflects the complete absence of any barrier: the attack vector is network, no user interaction is required, no prior authentication is needed, and the confidentiality, integrity, and availability of the host are all compromised.

GitHub advisory GHSA-7r6p-v9gw-pwc8 describes insufficient access control on WebSocket handlers exposing Dokploy's Docker terminals. The vulnerability is class CWE-285 — improper authorization.

Dokploy allows each user to access an interactive terminal in their containers via WebSocket. The check in place authenticated the user — it confirmed the presence of a valid token — but did not authorize: it did not verify that the requested service actually belongs to the requesting user. Any user with a valid account, even without administrative rights, could therefore open a terminal in any container belonging to any other user.

The actual impact goes beyond the container itself. Dokploy runs as root and mounts the host Docker socket (/var/run/docker.sock). From a shell inside a container, the command docker run --rm -v /:/host alpine chroot /host sh yields a root shell on the host filesystem. All versions below 0.29.13 are affected.

The CVE-2026-45631 + CVE-2026-72863 chain constitutes a complete attack achievable from any network, without a pre-existing account, in two steps.

Step 1 — Forge an admin token (CVE-2026-45631). The attacker knows the value better-auth-secret-123456789 from the public source code. They generate a JWT signed with this value, claiming the admin role. Dokploy's API accepts this token without further verification. The attacker now has full administrative access: list of all services, environment secrets, deployment keys.

Step 2 — Access a container terminal (CVE-2026-72863). With the forged admin token, the attacker opens a WebSocket connection to an arbitrary container's terminal. The absent authorization check lets the request through. The attacker has a shell inside the container.

Result — Root on the host. With Dokploy running as root with the Docker socket mounted, the attacker pivots from the container to the host. The entire filesystem, secrets from all hosted projects, SSH keys, and production environment variables are accessible. The entire operation requires no operator interaction and no pre-existing account on the instance.

Before proceeding with the update, accurately assess your instance's exposure.

Check the installed version: docker exec dokploy cat /app/package.json | grep '"version"'

If the version displayed is below 0.29.13, your instance is vulnerable to CVE-2026-72863. If it falls between 0.27.0 and 0.29.2, it is vulnerable to both CVEs simultaneously.

Check the JWT secret value: grep BETTER_AUTH_SECRET /etc/dokploy/.env

If the value is better-auth-secret-123456789 or the variable is absent, CVE-2026-45631 is actively exploitable on your instance regardless of the version.

Check network exposure: if your Dokploy interface is accessible from the Internet without IP restriction (firewall, Cloudflare Access, VPN), the attack surface is public. An attacker needs no prior network access to exploit CVE-2026-45631.

The update fixes both CVEs. These additional measures reduce the residual attack surface.

Restrict network access to the Dokploy interface. The Dokploy administration interface has no reason to be publicly accessible from the Internet. Limit access to port 3000 (or whichever port you use) to your team's IPs via the host firewall, or place Dokploy behind a VPN.

Enable multi-factor authentication (MFA). Dokploy has supported TOTP since version 0.28.0. Enable it for all administration accounts.

Audit project environment secrets. Dokploy stores the environment variables of your applications. If the instance was exposed during the vulnerability window (versions 0.27.0 to 0.29.12), consider all production secrets potentially read. Rotation recommended for API keys, database tokens, and application secrets.

Docker socket and least-privilege principle. The Docker socket mounted as a volume is a documented and exploited attack surface in CVE-2026-72863. Dokploy requires it to function, but access can be restricted via Docker socket proxy policies like Tecnativa/docker-socket-proxy to limit authorized operations.

These two vulnerabilities are serious, but the Dokploy maintainers' response deserves consideration before drawing conclusions about the project's maturity.

The advisories were published on September 25, 2026. The fix for CVE-2026-45631 was available in version 0.29.3, and the fix for CVE-2026-72863 in version 0.29.13 — both within a reasonable timeframe after responsible disclosure. The project maintains a security program via GitHub Security Advisories, indicating minimal maturity in vulnerability management.

Dokploy is a young project (first stable version in 2024) with rapid adoption: over 15,000 GitHub stars and a sustained release cadence. The presence of a hardcoded secret in early versions reflects security debt typical of fast-growing projects where ease of installation took priority over hardening defaults.

The project remains a relevant choice for teams wanting an accessible self-hosted PaaS, provided they follow security updates and apply the hardening measures described in this article.

If these vulnerabilities lead you to reconsider your self-hosted PaaS choice, here are the active alternatives in this segment.

Coolify is the closest alternative in terms of features. Open source, actively maintained, with a more mature security model for secret management (no documented hardcoded default value to date). Its interface is more complex but its codebase is larger and more audited.

Caprover is a proven option, older and therefore with a longer security track record. It is less active in terms of new features but more stable.

Portainer with Docker stacks remains a valid approach for teams that do not need a full PaaS. Portainer carries its own historical CVEs — notably around privilege escalation via the Docker API — but version 3.x has revised its authorization management.

Whatever alternative is chosen, applying the same hardening measures (restricted network access, MFA, regular secret rotation) remains the non-negotiable baseline.

CVE-2026-45631 (CVSS 10.0) and CVE-2026-72863 (CVSS 9.9) chain into an accountless-to-root-on-host attack. Any Dokploy instance below 0.29.13 with the default secret better-auth-secret-123456789 is compromisable from any network.

The fix requires two distinct and both mandatory steps: updating to version 0.29.13 minimum (docker compose pull && docker compose up -d), and regenerating BETTER_AUTH_SECRET in the .env file (openssl rand -base64 48). Either one without the other closes only half the surface.

After the update, restrict network access to the administration interface, enable MFA, and if the instance was exposed during the vulnerability window, rotate all hosted application secrets.