Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessReach Dockhand instance on network
-
DeliveryEnumerate valid target container ID
-
ExploitOpen unauthenticated WebSocket exec session
-
ExecutionExecute arbitrary commands in container
-
ImpactEscalate to host via privileged mode or sensitive mounts
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A07:2025 - Authentication Failures
ASVS 5.0
V6 - Authentication Authentication required for critical functions
MITRE ATT&CK
1 technique across 1 tactic: Initial Access The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires: (1) network reachability to a Dockhand instance running a version prior to 1.0.34; (2) knowledge or enumeration of a valid, running target container ID (the endpoint is /api/containers/<id>/exec); and (3) a target container that exposes an interactive shell. No authentication is needed because the WebSocket upgrade enforces none (CWE-306, PR:N). The command execution lands inside the container; full host compromise is a conditional escalation that applies ONLY when the targeted container runs in privileged mode or has sensitive host mounts (e.g., the Docker socket or host filesystem paths). The practical limiting factors for defenders are the need to know a specific container ID and the requirement that the container have an interactive shell - these constrain blind mass exploitation even though no credentials are required. |
| Impact | This is a genuine high-priority issue, not a CVSS-inflated one: CWE-306 (missing authentication) on the /api/containers/<id>/exec WebSocket upgrade means an unauthenticated actor who can reach Dockhand can open an interactive shell inside a container, and the S:C/C:H/I:H/A:H vector reflects realistic container-to-host escalation when the target container is privileged or has sensitive mounts (e.g., the Docker socket). The input provides NO EPSS score, NO CISA KEV listing, and NO public POC, so there is no public exploit identified at time of analysis and no evidence of active exploitation - the 9.6 severity is driven purely by the technical vector, not by observed attacker interest. Note a conflict between signals worth verifying: the vendor-supplied vector uses AV:A (adjacent), whereas the description ('has network reach to Dockhand') implies a general network-reachable WebSocket endpoint (AV:N), which would raise real exposure for instances exposed beyond a management segment - verify Dockhand's typical network placement. Two practical limiters temper the raw score: the attacker must know a valid target container ID and the target container must expose an interactive shell, so this is realistically exploitable but requires some target knowledge rather than being a blind internet-wide mass-exploitation primitive. |
| Exploit ScenarioDerived | An attacker with network access to a Dockhand instance older than 1.0.34 identifies or enumerates a running container ID and opens a raw WebSocket to /api/containers/<id>/exec, which performs no authentication on the upgrade. They obtain an interactive shell and run arbitrary commands inside that container; if the container is privileged or mounts sensitive host paths (such as the Docker socket), they pivot to full host compromise. No public exploit was identified at time of analysis, and the low attack complexity of the auth flaw itself makes a working client trivial to build once a container ID is known. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 16, 2026
Unauthenticated remote command execution inside containers managed by Dockhand (Finsys) affects all versions prior to 1.0.34: the WebSocket upgrade request for the in-browser terminal endpoint /api/containers/<id>/exec is served without any authentication check, so an attacker who can reach the instance and knows a running container ID can open a raw terminal session and run commands inside that container. No authentication is required (CVSS:3.1/PR:N, CWE-306), and the S:C/C:H/I:H/A:H scoring reflects realistic container-to-host escalation when the target container is privileged or exposes sensitive host mounts such as the Docker socket; exploitation is constrained in practice because the attacker must know or enumerate a specific container ID and the target must have an interactive shell. There is no confirmed active exploitation (not in CISA KEV) and no public exploit code identified at time of analysis, though the pre-auth nature and high EPSS-relevant profile make the issue high priority; a vendor-released patch exists in version 1.0.34.
RemediationAI
Apply the vendor-released patch: upgrade Finsys Dockhand to version 1.0.34 or later, which enforces authentication on the /api/containers/<id>/exec WebSocket upgrade (commit efb634701c55f80a8c752df8ae08d88f2c16cce9, release https://github.com/Finsys/dockhand/releases/tag/v1.0.34, advisory https://github.com/Finsys/dockhand/security/advisories/GHSA-f6q3-chhc-4hxm); check the running VERSION/UI footer to confirm the instance is actually on 1.0.34. Where immediate upgrade is not possible, the highest-value compensating control is to remove network reachability to the Dockhand API: bind it to localhost or a management VLAN, and place it behind a reverse proxy or VPN that performs its own authentication and, ideally, blocks the /api/containers/*/exec path entirely - the trade-off is that the in-browser terminal feature stops working for legitimate admins until the proxy rule is lifted. Do not rely on obscurity of container IDs: any authenticated or read-only Dockhand user, log output, or exposed Docker API can leak container IDs, so treat ID knowledge as an attacker-reachable precondition rather than a control. Additionally, reduce blast radius by running managed containers unprivileged, avoiding bind mounts of /var/run/docker.sock or host paths, and setting read-only root filesystems, so that a shell inside a container cannot pivot to the host via the Docker socket; the trade-off is that some administration workflows inside containers will need to be redesigned. If Dockhand's terminal feature can be disabled via configuration or by removing the exec route in a custom build, doing so eliminates the vulnerable surface entirely at the cost of losing interactive container access from the UI.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Dockhand is a Docker management application that provides a web UI, including an in-browser container terminal implemented as a WebSocket session at /api/containers/<id>/exec. The root cause is CWE-306 (Missing Authentication for Critical Function): the HTTP-to-WebSocket upgrade handler for that endpoint does not apply the authentication middleware that protects the rest of the API, so the upgrade completes for anonymous clients. Once upgraded, the session proxies directly into the container's interactive shell (equivalent to docker exec -it <id> /bin/sh), giving arbitrary command execution in the container's context under the identity Dockhand uses to talk to the Docker daemon. The affected component is the Finsys Dockhand application itself, identified in the CPE data as cpe:2.3:a:finsys:dockhand:*:*:*:*:*:*:*:* with all releases before 1.0.34 vulnerable. Because Dockhand typically reaches the Docker daemon with elevated privileges, command execution inside a container becomes host compromise when that container is started in privileged mode or bind-mounts sensitive host paths (notably /var/run/docker.sock or host filesystem directories) - this is why the impact is scored with Scope:Changed. The upstream fix is commit efb634701c55f80a8c752df8ae08d88f2c16cce9, which bumps VERSION to 1.0.34 and is shipped in release tag v1.0.34; note that the CNA's published vector is AV:A/AC:L/PR:N while our independent assessment models the same missing-auth defect as AV:N/AC:H/PR:N, differing only on whether the attacker must be adjacent and how much target-specific knowledge is needed.
Know when Dockhand gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:A/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
PR:N and UI:N reflect the complete absence of auth on the WebSocket upgrade; AC:H captures the required knowledge of a valid container ID plus a shell-bearing target; S:C/C:H/I:H/A:H reflect in-container RCE with conditional host escape.
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
2DescriptionCVE.org
Dockhand is a Docker management application. Prior to 1.0.34, the in-browser container terminal endpoint /api/containers/<id>/exec does not enforce authentication on the WebSocket upgrade request. When an unauthenticated attacker has network reach to Dockhand, knows a target container ID, and targets a container with an interactive shell, the attacker can open a raw WebSocket terminal session and execute commands inside a known target container. This allows unauthenticated command execution inside the container, with possible host compromise when the container has sensitive mounts or privileged execution. This issue is fixed in version 1.0.34.
Articles & Coverage 2
Technical POC Analysis
The bug class is CWE-306 Missing Authentication for Critical Function, per the supplied CVE data; the advisory itself lists no CWE.
Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.
Executive ViewAI
Dockhand (Finsys) deployments running any version prior to 1.0.34 expose an unauthenticated remote command execution path through the in-browser container terminal, meaning anyone who can reach the management interface and identify a running container can obtain a live shell inside it. Because container escape to the underlying host is realistic wherever privileged containers or host mounts such as the Docker socket are in use, a single unauthenticated request chain could put production workloads and the Docker host itself at risk. Leadership should treat this as an internet-facing attack surface problem affecting platform and infrastructure teams until a vendor fix is confirmed and deployed.
No vendor-released patch identified at time of analysis. Interim mitigations: remove internet exposure of Dockhand and restrict the management interface to trusted administrative networks; block or disable the /api/containers/<id>/exec endpoint and its WebSocket upgrade at the reverse proxy or WAF; place an authenticating proxy or mutual TLS in front of the API; eliminate privileged containers and Docker socket or sensitive host-path mounts; monitor for WebSocket upgrade attempts to the exec endpoint and for anomalous in-container process execution.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
EUVD-2026-102920
NVD
CVE.org
GitHub
Exploit-DB