GPU VulnDB

Database/Container, Kubernetes & orchestration

Dokploy: WebSocket handlers skip per-server authorization, giving any org member root terminals

CVSS 8.8CVE-2026-72883Container, Kubernetes & orchestrationcurated

Impact

The WebSocket handlers in terminal.ts, docker-container-terminal.ts, docker-container-logs.ts and docker-stats.ts check only that the caller belongs to the organization, never checkServiceAccess, accessedServerIds or accessedServices. Any authenticated organization member - including an account scoped to a single project - therefore gets a root shell on servers it was never granted, plus logs and stats for restricted services. Where Dokploy manages a mixed fleet, that is a full lateral move: root on the host means the Docker socket, every other tenant's containers, and any GPU device the host exposes. The per-server and per-service RBAC that the platform advertises is not enforced on these paths at all, so an operator's least-privilege model was never in effect.

Who can reach it

Authenticated but low privilege: any member of the Dokploy organization who can open a WebSocket to the Dokploy web app. No admin role, no server-level grant, and no local access to the managed host required.

What to do

Upgrade Dokploy to 0.29.13 and restart the app so the handlers enforce the access checks. Before that, treat every organization member as holding root on every managed server: cut the member list down to people who already have that trust, and put the Dokploy UI behind network restrictions so the WebSocket endpoints are not broadly reachable. After upgrading, rotate anything a root shell on the managed hosts would have exposed - registry credentials, deploy keys, environment secrets.

References

Related entries

All Container, Kubernetes & orchestration entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.