Summary
Dockhand before 1.0.40 contains an authentication bypass in its Git webhook endpoints caused by an ineffective check when a webhook secret is unset. An unauthenticated remote attacker may trigger stack redeployments, potentially causing denial of service or, when combined with write access to a tracked branch, achieve container escape and host compromise.
Affected context
The issue occurs in Dockhand Git webhook handling when a stack is configured with a null or absent webhook secret and the endpoint does not require an alternative authentication mechanism. The risk is greatest when stack identifiers are predictable, webhook endpoints are externally reachable, and redeployment performs Git and Docker Compose operations with elevated container or host privileges.
Exploit preconditions
- Attack surface: Git webhook endpoints exposed over a network
- Required access: No authentication may be required when the webhook secret guard is ineffective
- Trigger point: An incoming webhook request associated with a valid or discoverable stack identifier
- Additional escalation condition: Write access to the tracked Git branch may allow attacker-controlled deployment configuration to be processed
- Why exploitation is possible: The endpoint can authorize a redeployment despite the absence of a valid webhook secret
Why this happens
The vulnerability results from an authentication guard that does not safely handle a null or missing webhook secret. Instead of failing closed, the endpoint may accept unsigned requests and initiate privileged deployment actions. This maps to CWE-306: Missing Authentication for Critical Function, because a security-sensitive operation is reachable without reliable authentication.
Potential impact
- Unauthenticated attackers may trigger repeated stack redeployments
- Services may become unavailable or experience resource exhaustion
- Git repositories may be cloned repeatedly, increasing operational and network load
- Attacker-controlled deployment configuration could lead to code execution inside containers
- Containers may gain access to host resources when privileged mounts or excessive capabilities are configured
- The underlying host could be compromised in deployments with unsafe container privileges
General mitigation guidance
Mitigation generally focuses on ensuring that every webhook-triggered deployment requires strong, fail-closed authentication and that deployment privileges are minimized.
Common defensive patterns include:
- Rejecting requests whenever a webhook secret is missing, invalid, or ambiguously configured
- Using authenticated, integrity-protected webhook verification with constant-time secret comparison
- Avoiding predictable identifiers as the sole authorization control
- Restricting webhook exposure through network policy, ingress controls, or private connectivity
- Running deployment workers with least privilege and without unnecessary host mounts, privileged mode, or excess capabilities
- Treating Git-controlled deployment files as untrusted input and applying schema and policy validation before execution
- Separating deployment credentials and runtime privileges from application containers
How teams detect issues like this
High-level detection can include:
- Static analysis for authentication conditions that treat null, empty, or absent secrets as authorized states
- Code review of webhook handlers for fail-open branches and authorization checks performed after deployment actions are selected
- Tests covering missing-secret, invalid-secret, replay, and unauthorized-stack scenarios
- Monitoring for unsigned webhook requests, unusual stack enumeration patterns, and redeployments without corresponding verified Git events
- Policy enforcement that blocks privileged containers, host filesystem mounts, and excessive capabilities in deployment manifests
- Automated security review tools that flag missing authentication on critical endpoints and unsafe container configuration
