[sec-check] pull_request_target + reusables pinned to @main + secrets:inherit — pwn-request chain in 4 workflows

## Security Finding **Severity**: high **Type**: unsafe-pattern (pwn-request / supply-chain) Three console-kb workflows combine three attacker-favourable properties in the same job: 1. Triggered by `pull_request_target` — so `github.token` and `secrets` come from the **base** repository, not the fork PR. 2. Delegate to a `kubestellar/infra` reusable pinned to `@main` (a mutable ref) — so a compromise or unreviewed change in `kubestellar/infra` is executed here immediately. 3. Grant elevated write scopes and/or `secrets: inherit`, so a malicious reusable would run against console-kb with high-privilege credentials. The affected workflows are: | Workflow | Trigger | Perms | Reusable ref | Secret exposure | |---|---|---|---|---| | `.github/workflows/ai-fix.yml` | `pull_request_target: [opened]` + `issues:[labeled]` | `contents:write`, `issues:write`, `pull-requests:write` | `kubestellar/infra/.github/workflows/reusable-ai-fix.yml@main` | `secrets.GITHUB_TOKEN` | | `.github/workflows/copilot-automation.yml` | `pull_request_target: [opened, synchronize, ready_for_review]` | `contents:write`, `issues:write`, `pull-requests:write`, `statuses:write` | `kubestellar/infra/.github/workflows/reusable-copilot-automation.yml@main` | `secrets.GITHUB_TOKEN` | | `.github/workflows/pr-verifier.yml` | `pull_request_target: [opened, edited, synchronize, reopened]` | `checks:write`, `pull-requests:read` | `kubestellar/infra/.github/workflows/reusable-pr-verifier.yml@main` | `secrets: inherit` (all org secrets) | | `.github/workflows/greetings.yml` | `pull_request_target: [opened, reopened]` | `issues:write`, `pull-requests:write` | `kubestellar/infra/.github/workflows/reusable-greetings.yml@main` | `secrets: inherit` | ## Impact If an attacker can push any commit to `kubestellar/infra`'s `main` (unreviewed contributor, mis-clicked merge, compromised maintainer account, or dependency-review bypass on that repo), the next PR opened against `console-kb` will run their code with `contents:write` + a `GITHUB_TOKEN` for console-kb — enough to push to `master`, tamper with the mission index, publish releases via the same actions, or exfiltrate `secrets` inherited from console-kb / the org (`pr-verifier.yml` and `greetings.yml` use `secrets: inherit`, which forwards every configured secret). The `pull_request_target` trigger means this happens on PRs from forks, which is the exact class of untrusted input the pattern was invented to attract. This is distinct from the earlier "reusables pinned to @main" hygiene finding (bead `7001721e-2db`), which was framed as a Scorecard/Pinned-Dependencies issue; here the concern is the compound `pull_request_target` + mutable-ref + elevated-perms attack chain. ## Recommendation For each of the four workflows above: 1. **Pin the reusable to an immutable commit SHA** (with a comment naming the tag), e.g. ```yaml uses: kubestellar/infra/.github/workflows/reusable-ai-fix.yml@<40-char-sha> # v1.2.3 ``` Update the SHA via Dependabot (or a bot-authored PR) rather than tracking `@main`. 2. **Downgrade `pull_request_target` where possible**. `pr-verifier.yml` and `greetings.yml` almost certainly don't need repository write scopes on the base — evaluate whether `pull_request` (fork-scoped token) is sufficient, or whether the reusable can be split into a low-privileged "read PR context" job on `pull_request` and a separately-triggered write job on `workflow_run`/`issue_comment` guarded by author association. 3. **Replace `secrets: inherit`** with an explicit `secrets:` block that only forwards the specific secrets the reusable needs. `inherit` is a footgun the moment the reusable at `@main` starts reading a new secret name. 4. **Never check out the PR head** (`${{ github.event.pull_request.head.sha }}` / `head.ref`) inside a `pull_request_target` job unless the code path is strictly read-only. Verify this in the `kubestellar/infra` reusables as part of the audit. --- *Filed by sec-check agent (ACMM L6