Plaintext secret disclosure in Finsys Dockhand Git-stack responses

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.

• Finsys dockhand: releases 1.0.47 through 1.0.53 are affected by the semver range starting at 1.0.47 and ending before 1.0.54.
• Release 1.0.54 is explicitly identified by the CNA and advisory as patched or unaffected.
• The practical scope is Git stacks whose secrets are resolved, including stored secrets and secrets retrieved from external providers. The affected paths are the Git-stack webhook, manual Git deploy, and create-and-deploy routes.
• The advisory distinguishes the non-Git route POST /api/stacks/{name}/deploy, which returns a limited result and is not described as affected by the same issue.
• The record does not independently establish the status of parallel branches or later branches beyond the release explicitly identified as fixed.

During a Git stack deployment, deployStack() adds the plaintext value of every resolved secret to the result object as resolvedSecrets. That result is propagated through deployGitStack, and three Git-stack routes return or stream the object without removing the sensitive field: the Git-stack webhook returns json(result), manual Git deploy sends result over SSE, and create-and-deploy includes it in deployResult. An attacker must hold the stack webhook secret or have the stacks:start permission, and the stack must resolve at least one stored or external-provider secret. Under those conditions, the network response can contain every resolved secret for the stack, including values that a user without the secrets permission would otherwise not be allowed to view. The public sources describe the mechanism and suggested fix, but do not establish the exact internal implementation of the security patch.

The flaw is reachable over the network through the Git-stack webhook, manual deploy, and create-and-deploy endpoints. The webhook requires the stack's webhook secret, while the other deployment paths require stacks:start, so exploitation is not anonymous. Once the required credential or permission is available, no additional user interaction is required and the attack does not require complex conditions. The record identifies public exploit material and the advisory documents reproducible behavior, but it does not name a campaign, victim, or specific abuse case.

The flaw removes the confidentiality boundary around every secret resolved for the targeted Git stack, rather than disclosing only deployment metadata. A person with the webhook secret or stacks:start permission can receive stored and external-provider values that they may not otherwise be authorized to read. Forge or CI retention can create additional copies of the credentials and extend exposure to repository administrators or log readers. The evidence does not show that the flaw directly enables data modification or availability impact, but exposed credentials may have consequences outside Dockhand depending on their permissions.

• Plaintext credentials from stored secrets and external providers may be disclosed; depending on each credential's scope, the recipient may gain access to protected systems or services.
• Git forges may store webhook response bodies in delivery history, while CI scripts may write the responses to CI logs, expanding the audience that can read the secrets.
• Users with only stacks:start may see secrets even without the secrets permission that Dockhand otherwise requires before a provider can be bound to a stack.
• The record describes a confidentiality failure and does not describe direct modification of data or service interruption caused by the flaw.

1. Upgrade Finsys dockhand to 1.0.54, the release explicitly identified by the advisory as patched. Do not infer the status of unverified parallel branches.
2. Rotate stored credentials and external-provider credentials that may have appeared in webhook responses, SSE responses, forge delivery history, CI logs, or terminal logs. Review and rotate stack secrets where earlier deployment responses may have been retained.
3. Until upgrading, do not print or log complete webhook response bodies in scripts or CI. Retain only safe fields such as success, skipped, or exitCode when they are required.
4. Temporarily avoid directing forge push hooks to Dockhand webhooks when the forge stores response bodies, and review existing delivery history.
5. For maintainers, ensure that resolvedSecrets never crosses the API boundary of the webhook, manual-deploy, or create-and-deploy paths. Remove the field before returning or streaming the response, or keep it on an internal channel, and add regression tests confirming that none of the three responses contains the field.

1. Inventory Dockhand instances and identify Git stacks containing stored secrets or secrets retrieved from external providers such as 1Password, Bitwarden, Vault, Infisical, or Doppler.
2. Review API access logs and reverse-proxy logs for requests to api/git/stacks/{id}/webhook, api/git/stacks/{id}/deploy, and api/git/stacks that perform deployments.
3. Inspect GitHub, GitLab, Gitea, or Forgejo delivery histories and CI logs that may have recorded webhook response bodies. Search for the resolvedSecrets field or plaintext credentials in retained content.
4. For manual deploy and create-and-deploy operations, inspect browser network traces or SSE captures for result or deployResult events containing resolvedSecrets.
5. If a response contained secrets, treat the related values as potentially exposed and rotate them. The absence of matching logs or retained responses does not prove that an instance is safe.