Security: example fro-bot.yaml exposes secrets to fork PRs via issue_comment checkout

[marcusrbrown]

Summary

The example Fro Bot workflow (docs/examples/fro-bot.yaml) has a HIGH-severity secret-exfiltration vector on issue_comment events against fork PRs. Anyone copying the example inherits it.

The vulnerability

issue_comment events do not populate github.event.pull_request — a PR comment is exposed only as github.event.issue.pull_request. The job's fork guard checks github.event.pull_request.head.repo.fork, which is null/absent for issue_comment, so the fork guard does not apply to PR comments.

The checkout step then resolves PR-head code for comment-on-PR events:

ref: >-
  ${{
    (github.event.issue.pull_request && format('refs/pull/{0}/head', github.event.issue.number))
    || github.event.pull_request.head.sha
    || ''
  }}
token: ${{ secrets.FRO_BOT_PAT }}

Attack path

1. A trusted collaborator (OWNER/MEMBER/COLLABORATOR) comments @fro-bot on a fork PR.
2. The job if: passes — author_association authenticates the commenter, not the PR head code, and the fork guard is blind here.
3. Checkout pulls refs/pull/<n>/head — the fork's code — with secrets.FRO_BOT_PAT.
4. The secret-bearing agent step (and any post-checkout setup/run steps) then execute against attacker-controlled workspace content with FRO_BOT_PAT, OPENCODE_AUTH_JSON, OPENCODE_CONFIG present.
5. A malicious fork modifies executable repo files (a local composite action, package scripts, config, prompt-injection surfaces) to exfiltrate those secrets.

Severity is HIGH (potentially critical): FRO_BOT_PAT is a long-lived PAT for the fro-bot user, so compromise persists until rotation and can cross repository boundaries.

Remediation

The minimal safe fix is to never check out PR-head code — drop the ref: PR-head expression so checkout uses the default/workflow ref (the pattern already used safely in fro-bot/.github's own fro-bot.yaml). @fro-bot mentions then operate on the default branch rather than PR-head code.

If running against same-repo PR code via mention is a desired feature, gate it behind a no-checkout preflight: use GITHUB_TOKEN to call gh api repos/{owner}/{repo}/pulls/{n}, confirm head.repo.full_name == github.repository, and only then check out the exact head SHA — gating checkout and every secret-bearing step on that result. Fork PRs must never reach a secret-bearing checkout.

Recommend also strengthening the pull_request guard from !head.repo.fork to an explicit head.repo.full_name == github.repository check, and adding persist-credentials: false to checkout as defense-in-depth.

Since this is the canonical example users copy, fixing it here prevents the vector from propagating to every downstream workflow.

[fro-bot]

Triage: Confirmed HIGH-severity secret-exfiltration vector

I reproduced this by static analysis of docs/examples/fro-bot.yaml and cross-checking against the safe reference workflow in fro-bot/.github. The vulnerability is real and exactly as reported.

Confirmation

1. The fork guard is blind to issue_comment events (fro-bot.yaml:348-354):

github.event.pull_request == null ||
( !github.event.pull_request.head.repo.fork && ... )

For issue_comment, github.event.pull_request is null, so the first branch (== null) short-circuits to true — the fork check never runs. PR identity for a comment lives only in github.event.issue.pull_request.

2. Checkout then pulls fork-head code with the PAT (fro-bot.yaml:386-397):

ref: ${{ (github.event.issue.pull_request && format('refs/pull/{0}/head', github.event.issue.number)) || ... }}
token: ${{ github.event_name == 'workflow_dispatch' && secrets.GITHUB_TOKEN || secrets.FRO_BOT_PAT }}

On a PR comment, github.event.issue.pull_request is truthy → checkout resolves refs/pull/<n>/head (the fork's code) with secrets.FRO_BOT_PAT.

3. Secret-bearing step runs against attacker-controlled tree (fro-bot.yaml:401-419): the Run Fro Bot step (and any CUSTOMIZE setup steps inserted before it) execute with FRO_BOT_PAT + OPENCODE_AUTH_JSON present in a workspace a malicious fork controls (composite actions, package scripts, config, prompt-injection surfaces).

Attack path (validated against the guard logic)

1. A trusted collaborator (OWNER/MEMBER/COLLABORATOR) comments @fro-bot on a fork PR.
2. Job if: passes — author_association authenticates the commenter, not the head code; fork guard is bypassed (null pull_request).
3. Checkout pulls refs/pull/<n>/head with FRO_BOT_PAT.
4. Fork-controlled executable files run with secrets in env → exfiltration.

Severity: HIGH (→ critical). FRO_BOT_PAT is a long-lived PAT for the fro-bot user; compromise persists until rotation and can cross repo boundaries. Because this is the canonical example users copy, every downstream workflow inherits the flaw.

Reference pattern confirms the fix

I checked fro-bot/.github's own fro-bot.yaml: its checkout step has no ref: expression — it uses the default/workflow ref. The minimal safe fix is to make the example match that pattern.

Proposed next steps

Fix (minimal, recommended): Remove the PR-head ref: expression from the checkout step (lines 386–391) so checkout always uses the default ref. @fro-bot mentions then operate on the default branch, never fork-head code.

Defense-in-depth (also recommended):

1. Strengthen the pull_request guard from !head.repo.fork to explicit github.event.pull_request.head.repo.full_name == github.repository (lines 352–353).
2. Add persist-credentials: false to the checkout step.

Optional (only if same-repo PR-head checkout via mention is a desired feature): Gate it behind a no-checkout preflight — use GITHUB_TOKEN to call gh api repos/{owner}/{repo}/pulls/{n}, confirm head.repo.full_name == github.repository, and only then check out the exact head SHA, gating checkout and every secret-bearing step on that result. Fork PRs must never reach a secret-bearing checkout.

I recommend the minimal fix + both defense-in-depth items. The preflight-gated same-repo checkout is more surface area than the example warrants; downstream users who need it can opt in. Suggest also adding a short SECURITY note in the file header explaining why checkout never uses PR-head code, so copiers don't reintroduce it.

I can open a PR implementing the minimal fix plus the two defense-in-depth changes on request.

---

Run Summary

Field	Value
Event	issues
Repository	fro-bot/agent
Run ID	27520962073
Cache	hit
Session	ses_136d2d934ffeKyHz5S2UBrthCJ