Impact

• Command injection can exfiltrate secrets from the CI environment, most critically the FISHTOWN_BOT_PAT which grants access to repositories via the FishtownBuildBot account, escalating the impact beyond a single runner.
• Arbitrary shell execution lets an attacker manipulate workflow logic, alter outputs, and—if the bot PAT is stolen—perform authenticated actions as FishtownBuildBot across accessible repositories.
• Injected commands can fail jobs, hang runners, or consume resources, disrupting the automation pipeline.

Patches / Workarounds

There are no associated dbt core patches or workarounds that mitigate this vulnerability as the vulnerability was not user facing.

Vulnerability Description

Inside the reusable workflow dbt-labs/actions/blob/main/.github/workflows/open-issue-in-repo.yml, the prep job uses peter-evans/find-comment to search for an existing comment indicating that a docs issue has already been opened. The output steps.issue_comment.outputs.comment-body is then interpolated directly into a bash if statement:

if [ '${{ steps.issue_comment.outputs.comment-body }}' = '' ]; then
  echo "exists=false" >> $GITHUB_OUTPUT
  title="Continue Processing."
  message="Opening a new issue in ${{ inputs.issue_repository }}."
else
  echo "exists=true" >> $GITHUB_OUTPUT
  title="Stop processing."
  message="Comment already exists for this issue or PR indicating an associated issue. New issue will not be opened."
fi
echo "::notice $title::$message"

A particularly important aspect of the behavior is that the workflow logic treats the result of the comment lookup as trusted workflow state, even though it may originate from an untrusted issue comment. If the search used by find-comment is intended to identify a prior bot comment but does not sufficiently constrain the comment author, an attacker may be able to post a matching comment ahead of the workflow and have their own attacker-controlled comment body pulled into the injection sink. In practice, this turns the issue into a comment-spoofing variant of command injection: the workflow believes it is processing an existing automation marker, but may instead be consuming attacker-supplied text.

Because comment-body is attacker-controlled text and is inserted into shell syntax without escaping, a malicious comment body can break out of the quoted string and inject arbitrary shell commands.

This establishes a real command injection vulnerability in the reusable workflow.

Mitigations

1. Do not interpolate untrusted workflow values directly into shell code

   Never place attacker-controlled values such as comment bodies inside run: shell scripts without safe escaping.

2. Use environment variables and robust quoting

   Pass untrusted values through environment variables and compare them safely in bash, for example with:

COMMENT_BODY="$SAFE_VALUE"
if [ -z "$COMMENT_BODY" ]; then
  ...
fi

Depi x Gato-X

This vulnerability has been found with the implementation of Gato-X, a scanning and attack tool for GitHub Actions pipelines, inside Depi an Upstream Security Platform.

The viability of the exploit has been tested locally with act and reviewed by Adnan Khan and Roni Carta.