GitHub Actions Workflow Security Audit — Post-Incident Hardening

[north-echo]

Update (March 18): After forking and auditing against current main, I found the maintainers have already addressed the majority of the issues outlined above including removing the exploited workflows, fixing script injections across multiple files, SHA-pinning actions, adding persist-credentials: false, and integrating the zizmor linter. The remaining gaps are narrower than originally scoped: 3 secret exposure fixes, 1 script injection fix, and 20 missing permissions: blocks. PR incoming with the fixes and a full audit report.

Description

Following the March 1, 2026 security incident (Discussion #10265), the exploited apidiff.yaml workflow was removed in PR #10259. However, no comprehensive audit of the remaining .github/workflows/ files has been conducted to verify they are not susceptible to the same classes of vulnerability that were exploited in the hackerbot-claw campaign.

Community members in Discussion #10265 have noted that the vulnerable pull_request_target pattern had been present since at least October 2025 and called for a full evaluation of other workflows. This issue proposes a systematic audit and hardening of all remaining GitHub Actions workflows against the exploitation techniques used in the campaign.

Scope

Audit all files in .github/workflows/ and .github/actions/ for the following vulnerability classes, based on the five techniques used across the hackerbot-claw campaign:

1. Pwn Request (pull_request_target + untrusted checkout)
Workflows using on: pull_request_target that check out PR head code (github.event.pull_request.head.sha or head.ref) and execute it. This was the exact pattern exploited in the Trivy incident.

Check: Any remaining pull_request_target triggers should either be removed, replaced with pull_request, or refactored so that no fork-supplied code is checked out or executed in the privileged context.

2. Script injection via ${{ }} expression interpolation
Unsanitized use of attacker-controlled GitHub context expressions (e.g., ${{ github.event.pull_request.title }}, ${{ github.head_ref }}, ${{ github.event.issue.body }}) inside run: blocks. These allow arbitrary command injection via crafted PR titles, branch names, or issue bodies.

Check: All ${{ }} expressions in run: blocks should be moved to environment variables using env: mappings, which are not subject to shell interpretation.

3. issue_comment triggers without authorization gates
Workflows triggered by issue_comment that execute commands (e.g., /format, /test) without checking github.event.comment.author_association for MEMBER or OWNER. Any GitHub user can leave a comment on a public issue/PR, so ungated triggers allow arbitrary external users to invoke CI actions.

Check: All comment-triggered workflows should gate execution on author_association.

4. Overly broad token permissions
Workflows running with contents: write, pull-requests: write, or other elevated permissions when contents: read would suffice. Broader permissions increase the blast radius if a token is exfiltrated.

Check: Each workflow's permissions: block should follow least privilege. Where no permissions: block exists, the workflow inherits the repository default, which should also be reviewed.

5. PAT usage where GITHUB_TOKEN would suffice
Workflows that use Personal Access Tokens or other long-lived secrets when the ephemeral, automatically-scoped GITHUB_TOKEN would be sufficient. The Trivy incident escalated from CI code execution to full repository compromise specifically because a PAT with broad permissions was available in the workflow environment.

Check: Identify any workflows that expose PATs or other long-lived credentials and evaluate whether they can be replaced with GITHUB_TOKEN at minimum required scopes.

Additional Considerations

• Third-party action pinning: Actions should be pinned to full commit SHAs rather than mutable tags to prevent upstream compromise (as seen in the tj-actions/changed-files incident).

• Composite actions: .github/actions/ subdirectories should be audited with the same criteria, since they execute within the calling workflow's permission context.

References

Discussion #10265 — Trivy security incident 2026-03-01
PR #10259 — Removal of exploited apidiff workflow
PR #8720 — Prior hardening of semantic-pr.yaml
StepSecurity: hackerbot-claw exploitation campaign analysis
GitHub Docs: Security hardening for GitHub Actions

Proposal
I'd like to conduct this audit and submit a PR with findings and fixes. Happy to coordinate with maintainers on scope and approach before starting work.

Target

None

Scanner

None

[north-echo]

PR submitted: #10417

Changes:

• 3 secret exposure fixes — moved secrets.GPG_KEY and secrets.ORG_REPO_TOKEN off command lines into env: variables (release.yaml, publish-chart.yaml, release-please.yaml)
• 1 script injection fix — matrix.operating-system moved to env var in test.yaml
• 20 missing permissions: blocks — added explicit least-privilege scopes to all workflows

A full audit report is included in the PR covering all 26 findings across 22 workflows and 2 composite actions. Priority 2/3 items (third-party action replacement in publish-chart.yaml, pip URL token pattern in mkdocs workflows, ORG_REPO_TOKEN scope review) are flagged for maintainer input.