dbt workflow command injection enables CI runner code execution

TL;DR — A reusable dbt GitHub Actions workflow can be tricked into running attacker-controlled shell commands by interpolating untrusted issue-comment text into a bash if statement.

What happened

dbt is a popular data transformation toolchain, and dbt-labs/actions provides reusable GitHub Actions workflows used to automate repo tasks. CVE-2026-39382 describes a Critical command injection issue in the reusable workflow dbt-labs/actions/blob/main/.github/workflows/open-issue-in-repo.yml.

Per the CVE record and linked advisory, the workflow’s prep job uses peter-evans/find-comment to locate an existing comment, then interpolates steps.issue_comment.outputs.comment-body directly into a bash if expression. Because the comment body can be attacker-controlled and is inserted into shell syntax without escaping, a crafted comment can break out of quoting and inject arbitrary commands.

The advisory notes this can lead to CI secret exfiltration and broader automation compromise (e.g., if a privileged bot token is present in the workflow environment), not just a single job failure.

This is the same failure mode that keeps showing up in CI/CD incidents: treating untrusted content (issue/PR text, comment bodies, or tool outputs derived from them) as trusted shell syntax in privileged automation.

Who is impacted

• Repositories that consume the reusable workflow dbt-labs/actions/.github/workflows/open-issue-in-repo.yml from commits before bbed8d28354e9c644c5a7df13946a3a0451f9ab9.
• Workflows where the comment-search behavior can be influenced by an attacker (for example, if the search is not sufficiently constrained to a trusted author and can be satisfied by an attacker’s “spoofed” comment).
• Any CI environment where the job has access to sensitive secrets/tokens (the advisory highlights the risk of secrets exfiltration and privileged bot credentials).

What to do now

• Follow vendor remediation guidance.

  "This vulnerability is fixed with commit bbed8d28354e9c644c5a7df13946a3a0451f9ab9."

• Inventory where your org references dbt-labs/actions reusable workflows and identify any usage of open-issue-in-repo.yml pinned to an older ref (branch/tag/SHA).
• Treat this as CI compromise-prone until you’ve validated your exposure:
  • review recent workflow runs that executed this reusable workflow
  • rotate secrets exposed to the workflow if suspicious activity is found
• Apply the mitigation guidance from the advisory to your own workflows (this issue class is broader than dbt):

  "Do not interpolate untrusted workflow values directly into shell code" "Pass untrusted values through environment variables and compare them safely in bash"

• If you use comment-search automation patterns (e.g., find-comment), ensure the workflow constrains the match to trusted authors/markers so attacker-authored comments can’t be selected as “trusted state.”