Summary
Dockhand's container terminal WebSocket endpoint does not enforce authentication during the WebSocket upgrade, allowing an unauthenticated attacker with network access to open a terminal session in an eligible container. If the attacker knows the container ID and the container provides an interactive shell, they may execute commands inside it, with greater consequences when sensitive mounts or privileged settings are present.
Dockhand's container terminal WebSocket endpoint does not enforce authentication during the WebSocket upgrade, allowing an unauthenticated attacker with network access to open a terminal session in an eligible container. If the attacker knows the container ID and the container provides an interactive shell, they may execute commands inside it, with greater consequences when sensitive mounts or privileged settings are present.
Affected context
The issue occurs in Dockhand deployments where the in-browser terminal endpoint handles WebSocket upgrades without verifying the requester's identity and authorization. Risk is greatest when the service is network-reachable, a container identifier can be obtained or guessed, and the target container exposes an interactive shell through the terminal functionality.
The issue occurs in Dockhand deployments where the in-browser terminal endpoint handles WebSocket upgrades without verifying the requester's identity and authorization. Risk is greatest when the service is network-reachable, a container identifier can be obtained or guessed, and the target container exposes an interactive shell through the terminal functionality.
Exploit preconditions
- Attack surface: The Dockhand container terminal WebSocket endpoint at
/api/containers/<id>/exec - Required access: Network reachability to Dockhand, without necessarily having an authenticated application session
- Required target knowledge: A valid target container ID
- Trigger point: The WebSocket upgrade request for an interactive container terminal
- Why exploitation is possible: Authentication and authorization are not enforced before the terminal session is established
- Attack surface: The Dockhand container terminal WebSocket endpoint at
/api/containers/<id>/exec - Required access: Network reachability to Dockhand, without necessarily having an authenticated application session
- Required target knowledge: A valid target container ID
- Trigger point: The WebSocket upgrade request for an interactive container terminal
- Why exploitation is possible: Authentication and authorization are not enforced before the terminal session is established
Why this happens
The vulnerability results from treating a WebSocket upgrade as a trusted internal request instead of applying the same authentication and authorization controls used by the surrounding application. Because the terminal endpoint accepts the upgrade without validating the caller's identity and permission to access the selected container, an unauthenticated party can reach a command-execution capability. This maps primarily to CWE-306: Missing Authentication for Critical Function, with CWE-862: Missing Authorization also applying because access to a specific container operation is not properly restricted.
The vulnerability results from treating a WebSocket upgrade as a trusted internal request instead of applying the same authentication and authorization controls used by the surrounding application. Because the terminal endpoint accepts the upgrade without validating the caller's identity and permission to access the selected container, an unauthenticated party can reach a command-execution capability. This maps primarily to CWE-306: Missing Authentication for Critical Function, with CWE-862: Missing Authorization also applying because access to a specific container operation is not properly restricted.
Potential impact
- Unauthenticated attackers may execute commands inside an eligible container
- Application data, secrets, or mounted files could be accessed or altered
- Container workloads may be disrupted or modified
- Host compromise could occur when containers expose sensitive host mounts or privileged execution
- Attackers could use the container as a foothold for lateral movement
- Unauthenticated attackers may execute commands inside an eligible container
- Application data, secrets, or mounted files could be accessed or altered
- Container workloads may be disrupted or modified
- Host compromise could occur when containers expose sensitive host mounts or privileged execution
- Attackers could use the container as a foothold for lateral movement
General mitigation guidance
Mitigation should center on enforcing identity and permission checks before any terminal WebSocket session is accepted.
Defensive patterns include:
- Require authenticated sessions for the WebSocket handshake
- Authorize the requested container and terminal operation for the identified user or service identity
- Apply the same access-control policy to WebSocket routes as to ordinary HTTP routes
- Use short-lived, scoped terminal capabilities rather than broadly trusted endpoint access
- Restrict network exposure of management interfaces through segmentation and administrative access controls
- Run containers with least privilege, minimal mounts, and no unnecessary host access
- Log, monitor, and rate-limit terminal session creation and command-execution activity
Mitigation should center on enforcing identity and permission checks before any terminal WebSocket session is accepted.
Defensive patterns include:
- Require authenticated sessions for the WebSocket handshake
- Authorize the requested container and terminal operation for the identified user or service identity
- Apply the same access-control policy to WebSocket routes as to ordinary HTTP routes
- Use short-lived, scoped terminal capabilities rather than broadly trusted endpoint access
- Restrict network exposure of management interfaces through segmentation and administrative access controls
- Run containers with least privilege, minimal mounts, and no unnecessary host access
- Log, monitor, and rate-limit terminal session creation and command-execution activity
How teams detect issues like this
Organizations can look for this class of issue through:
- Static analysis and route reviews that identify WebSocket handlers lacking authentication middleware
- Code review checks confirming authentication and object-level authorization occur before session upgrades
- Dynamic tests that attempt unauthenticated WebSocket connections to administrative and terminal endpoints
- Policy enforcement requiring centralized identity validation for every management-plane route
- Monitoring for terminal sessions that lack a corresponding authenticated principal or authorization decision
- Automated security testing and code review tools configured to flag missing authentication and authorization controls
Organizations can look for this class of issue through:
- Static analysis and route reviews that identify WebSocket handlers lacking authentication middleware
- Code review checks confirming authentication and object-level authorization occur before session upgrades
- Dynamic tests that attempt unauthenticated WebSocket connections to administrative and terminal endpoints
- Policy enforcement requiring centralized identity validation for every management-plane route
- Monitoring for terminal sessions that lack a corresponding authenticated principal or authorization decision
- Automated security testing and code review tools configured to flag missing authentication and authorization controls
