CVE-2026-121449 in Dockhand
Summary
by MITRE • 11/03/2026
Dockhand from 1.0.47 before 1.0.54 exposes plaintext stack secrets because deployStack() attaches resolved secret values to its result as resolvedSecrets, which Git-stack routes return unfiltered. Holders of a stack's webhook secret or users with stacks:start permission can trigger the Git stack webhook, manual deploy, or create-and-deploy endpoints to receive stored and external-provider secrets such as 1Password or Vault values.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 11/03/2026
The vulnerability identified in Dockhand versions prior to 1.0.54 represents a critical information disclosure flaw rooted in improper handling of sensitive credentials within the application's deployment workflow. Specifically, the issue resides in the deployStack() function which is responsible for orchestrating stack deployments via Git-based workflows. During this process, the system resolves external secret values from providers such as 1Password or HashiCorp Vault and attaches these resolved plaintext secrets to a result object under the attribute name resolvedSecrets. This design choice creates a direct pathway for sensitive data leakage because the subsequent response handling mechanisms fail to sanitize or filter out these credentials before transmitting them back to the client or webhook caller.
The operational impact of this flaw is severe, as it allows unauthorized actors to retrieve plaintext secrets that are intended to remain confidential within the application's internal memory or secure storage layers. An attacker who possesses a stack's webhook secret can trigger the Git stack webhook endpoint, while users with stacks:start permissions can initiate manual deployments or use create-and-deploy endpoints. In both scenarios, the system processes the deployment request and returns the result object containing the resolvedSecrets field to the requester. Consequently, any entity capable of invoking these specific API endpoints gains access to sensitive configuration data, including database passwords, API keys, and other credentials stored in external secret management providers. This exposure undermines the fundamental security principle that secrets should never be transmitted over network channels unless strictly necessary for immediate cryptographic operations, and even then, they must be handled with extreme care.
From a classification perspective, this vulnerability aligns closely with CWE-209, which describes the generation of an error message that includes sensitive information about the software, the operating system, the database, or related components. More accurately, it falls under CWE-798, Use of Hard-coded Credentials, if viewed as improper storage and exposure, but primarily maps to CWE-312 Cleartext Storage of Sensitive Information in a File or Database when considering how the secrets are held in memory during transmission, and CWE-532 Insertion of Sensitive Information into Log File if logs were involved. In terms of attack vectors, this behavior is consistent with ATT&CK technique T1078 Valid Accounts, as it requires valid authentication credentials (either a webhook secret or user permission) to exploit the flaw through API interaction rather than an unauthenticated remote code execution vector.
Mitigation strategies must focus on immediate remediation and long-term architectural improvements. The primary fix involves modifying the deployStack() function and its associated response serialization logic to explicitly exclude resolvedSecrets from any data structures returned to external clients or webhook handlers. Developers should ensure that secret resolution occurs in a secure, isolated context where values are used only for their intended operational purpose within the application backend and are never serialized into JSON responses or HTTP bodies sent over the network. Additionally, implementing strict output encoding and filtering rules at the API layer can prevent accidental leakage of internal objects. For existing deployments running versions 1.0.47 through 1.0.53, immediate upgrading to version 1.0.54 or later is required to patch this vulnerability. Organizations should also audit their access control policies to ensure that webhook secrets and deployment permissions are granted on a least-privilege basis, minimizing the blast radius in case of future credential compromise.