Merge pull request #318 from HackTricks-wiki/update_Find_Comment_Get_Shell_Command_Injection_in_dbt__4f2a061f6bbf07ee

Find Comment, Get Shell Command Injection in dbt’s GitHub Ac...

Author: carlospolop

src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-context-script-injections.md

@@ -53,6 +53,46 @@ New issue uid=1001(runner) gid=118(docker) groups=118(docker),4(adm),100(users),
 Why quoting doesn’t save you:
 - Expressions are rendered first, then the resulting script runs. If the untrusted value contains $(...), `;`, `"`/`'`, or newlines, it can alter the program structure despite your quoting.
 
+## Comment-state confusion: spoofed bot comments → shell injection
+
+A dangerous variant appears when a workflow **searches comments and later treats the returned comment as trusted automation state**. For example, `peter-evans/find-comment` can search by `body-includes` and expose the matching `comment-body` as a step output. If the workflow does **not** also restrict `comment-author`, any user who can comment may spoof the marker text expected from a bot.
+
+```yaml
+- uses: peter-evans/find-comment@v4
+  id: fc
+  with:
+    issue-number: ${{ github.event.issue.number }}
+    body-includes: "Opened a new issue in org/repo:"
+```
+
+If that output is later embedded into shell syntax, the workflow becomes exploitable even though the original source was "just a comment":
+
+```yaml
+- run: |
+    if [ '${{ steps.fc.outputs.comment-body }}' = '' ]; then
+      echo "new issue needed"
+    fi
+```
+
+An attacker can post a comment that both:
+- matches the searched marker string, and
+- contains shell-breaking content such as `' ]; <cmd>; if [ 'x`
+
+After GitHub renders `${{ ... }}`, Bash receives attacker-controlled syntax, not data. This creates a **two-stage exploit**:
+1. **Provenance confusion**: the workflow mistakes attacker comments for bot state.
+2. **Script injection**: the returned `comment-body` is pasted into `run:` and executed.
+
+### TOCTOU race against bot comments
+
+If the legitimate bot comment is created only after some earlier step, an attacker may race it by posting the spoofed comment first. If the search action returns the attacker's comment before the real bot comment exists (or before it is selected), a low-privilege public commenter can turn an `issue_comment`/issue workflow into privileged runner execution.
+
+### Safer patterns for comment-driven automation
+
+- When using `find-comment`, require **both content and provenance** (`comment-author`, repository/App identity, or another strong binding).
+- Do not use comments as state if a label, artifact, issue field, or external datastore can hold the same state more safely.
+- Never paste `comment-body`, issue titles, labels, or any workflow output derived from them directly into `run:`.
+- If you must consume comment text, pass it through `env:` or a file and handle it as data only.
+
 ## Safe pattern (shell variables via env)
 
 Correct mitigation: copy untrusted input into an environment variable, then use native shell expansion ($VAR) in the run script. Do not re-embed with ${{ ... }} inside the command.
@@ -87,6 +127,10 @@ Accounts with only read permission on public repositories can still trigger many
 
 Which specific fields are attacker-controlled is event-specific. Consult GitHub Security Lab’s untrusted input guide: https://securitylab.github.com/resources/github-actions-untrusted-input/
 
+## Local validation without touching the target repo
+
+You can reproduce many GitHub Actions script injections safely with [`act`](https://github.com/nektos/act): generate a synthetic event JSON, run the vulnerable workflow locally, and replace the external action output with a controlled value (for example a mocked `comment-body`). This is useful to debug payload structure, verify whether the injected text still leaves valid Bash syntax, and confirm harmless canary exfiltration before any live test.
+
 ## Practical tips
 
 - Minimize use of expressions inside run:. Prefer env: mapping + $VAR.
@@ -96,6 +140,10 @@ Which specific fields are attacker-controlled is event-specific. Consult GitHub
 
 ## References
 
+- [Find Comment, Get Shell: Command Injection in dbt’s GitHub Actions](https://landh.tech/blog/20260701-find-comment-get-shell)
+- [peter-evans/find-comment](https://github.com/peter-evans/find-comment)
+- [GHSL-2023-109: GitHub Actions command injection in a TDesign Vue Next workflow](https://securitylab.github.com/advisories/GHSL-2023-109_TDesign_Vue_Next/)
+- [nektos/act](https://github.com/nektos/act)
 - [GitHub Actions: A Cloudy Day for Security - Part 1](https://binarysecurity.no/posts/2025/08/securing-gh-actions-part1)
 - [GitHub workflow syntax](https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions)
 - [Contexts and expression syntax](https://docs.github.com/en/actions/learn-github-actions/contexts)