Dockhand CVE-2026-121449

Requires a Git stack in Dockhand that has at least one resolvable secret bound to it - either a stored secret or a value from an external provider (1Password, Bitwarden, HashiCorp Vault, Infisical, Doppler, or Psono). The attacker must hold one of two things: the stack's webhook secret (triggering POST/GET /api/git/stacks/{id}/webhook), or a user account with the stacks:start permission (triggering the manual Git deploy /api/git/stacks/{id}/deploy or create-with-'Deploy now' /api/git/stacks endpoints). Notably the stacks:start path exposes secrets even to users who lack the secrets permission that Dockhand otherwise requires to bind a provider. Affected versions are 1.0.47 through 1.0.53 only; the non-Git route POST /api/stacks/{name}/deploy is not affected because it already returns only {success, output/error}. Limiting factors: this is not anonymous (needs the webhook secret or stacks:start), only Git-stack code paths are vulnerable, and a stack with no bound secrets leaks nothing. There is no configuration toggle to mitigate it short of upgrading to 1.0.54.

This is a genuine but bounded-priority confidentiality issue rather than an inflated high-CVSS score. The input CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H) scores 7.1 and is internally consistent with the description: network-reachable HTTP endpoints, low complexity, high confidentiality impact, and crucially PR:L - exploitation requires either possession of a stack's webhook secret or a user account with the stacks:start permission, so it is not an anonymous internet-wide bug. Integrity and availability impact are correctly N; this only leaks data. The vuln.today decision label is 'this_week', consistent with a real but non-emergency priority. It is NOT in CISA KEV, so there is no confirmed active exploitation, and no EPSS score was provided in the input, so probabilistic exploitation likelihood cannot be quantified here - that is a missing signal, not a low one. A detailed public PoC reference exists (the GHSA advisory includes a working curl reproduction and UI steps); it is not provided as packaged weaponized exploit code, but the trigger is fully documented. The signals do not conflict: a moderate-privilege confidentiality flaw with a documented reproduction and an available fix. The sharpest escalation factor is the one the CVSS score cannot capture - the leaked data is upstream provider secrets (1Password, Bitwarden, Vault, Infisical, Doppler, Psono) plus the fact that Git forges persist webhook response bodies in delivery history, so a single leaked webhook reply can expose high-value credentials to anyone with repository-admin access at the forge or anyone reading CI logs.

An operator holding only a stack's webhook secret (a credential meant solely to trigger redeploys) sends a POST to /api/git/stacks/{id}/webhook and receives a JSON body containing resolvedSecrets - the plaintext values of every stored and external-provider secret bound to that stack. Alternatively, a low-privilege user with stacks:start but without the secrets permission clicks Deploy and reads the same values from the SSE 'result' event in browser network traffic. A detailed public PoC (curl command and UI steps) is documented in the GHSA advisory.