GPU VulnDB

Database/Container, Kubernetes & orchestration

Dockhand: unauthenticated WebSocket exec gives shell access inside any container whose ID is known

CVSS 9.6CVE-2026-57169Container, Kubernetes & orchestrationcurated

Impact

Dockhand's in-browser container terminal does not enforce authentication on the WebSocket upgrade for /api/containers/<id>/exec. Anyone who can reach the Dockhand service and knows a container ID can open a raw terminal session and run commands inside that container as whatever user its shell runs as. Container IDs are not secrets in any meaningful sense - they leak through logs, labels, compose files and other API surfaces. Where Dockhand manages hosts that run privileged containers or containers with sensitive bind mounts, including the GPU-device and driver mounts typical of accelerator workloads, this becomes host compromise on a node that cannot be drained for free. The management UI is normally the most-trusted thing pointed at a container host, so an auth bypass here is equivalent to handing over the Docker socket.

Who can reach it

Any party with network reach to the Dockhand service - adjacent network per the vendor's own vector - with no credentials. The attacker needs a target container ID and a container that has an interactive shell.

What to do

Upgrade to Dockhand 1.0.34, which enforces authentication on the WebSocket upgrade, and restart the service; it is a single management daemon, so no node drain is involved. Until then, remove network exposure of the Dockhand port - bind it to localhost or put it behind an authenticating reverse proxy - and treat any container it managed while exposed as suspect.

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.