Workflow security audit

[enyst]

I reviewed our GitHub Actions workflows for exposure to the attack chain described in https://adnanthekhan.com/posts/clinejection/ (LLM prompt injection → agent executes commands in CI → GitHub Actions cache poisoning → pivot into a more-privileged workflow to steal publish secrets).

What I reviewed

• Enumerated all 23 workflows in .github/workflows/.
• Flagged workflows using higher-risk triggers: issues, pull_request_target, workflow_run.
• Looked for:
  • LLM/agent execution (OpenHands / Claude / LLM usage)
  • secret exposure (secrets.*)
  • checkout of untrusted refs (PR head SHA/ref in pull_request_target)
  • cache usage (explicit setup-uv enable-cache: true, or other caching in privileged contexts)
  • overly-broad permissions: (e.g., id-token: write, actions: write) in jobs that could run untrusted code

Key findings

High risk

1. pr-review-by-openhands.yml + .github/actions/pr-review composite action

• Triggered via pull_request_target on opened/ready_for_review/labeled/review_requested.
• The composite action checked out:
  • the SDK tooling at sdk-version: ${{ github.event.pull_request.head.sha }} (i.e., untrusted PR code), and
  • the PR repo head.ref (untrusted),
    then ran the PR review agent with secrets available.
• This is a direct untrusted-code-execution path in a secrets-bearing pull_request_target workflow.
• It also enabled setup-uv GitHub Actions caching, which can contribute to cross-workflow cache poisoning/pivot patterns.

Mitigation: opened PR #2119 to harden this (details below).

Medium risk / defense-in-depth

2. auto-label-issues.yml

• Runs on issues: opened (public trigger) and used a long-lived PAT secret to add a label.
• The workflow does not need a PAT; the ephemeral GITHUB_TOKEN with issues: write is sufficient.

Mitigation: included in PR #2119.

3. integration-runner.yml

• Uses pull_request_target and checks out PR head SHA for label-triggered runs (expected for integration tests).
• setup-matrix previously ran on any label event (even non-test labels) and imported python code from the checked-out PR.
• run-integration-tests granted id-token: write (OIDC) despite no usage.

Mitigation: included in PR #2119 (gate setup-matrix to relevant triggers + remove id-token: write).

4. condenser-runner.yml

• Similar label-triggered pull_request_target pattern. Also granted id-token: write without usage.

Mitigation: included in PR #2119.

PR with fixes

• security: Harden GitHub workflows against prompt injection cache pivots #2119

Summary of changes:

• PR review now runs only on maintainer-applied review-this label.
• Composite PR review action no longer checks out PR head code (uses trusted base commit + GitHub API diffs).
• Disabled setup-uv Actions cache for the PR review action.
• Switched issue auto-label to GITHUB_TOKEN.
• Removed unused id-token: write from label-triggered pull_request_target jobs.

Recommended follow-ups (not included)

• Consider additional guardrails for any CI LLM/agent runs:
  • run agents with a minimal tool allowlist (avoid unrestricted bash/network where possible)
  • use fine-grained tokens with least privilege for commenting/reviewing
  • consider GitHub environments + required reviewers for workflows that must use highly-privileged secrets
  • avoid using shared caches in any workflow that has publish credentials, or salt cache keys with a secret only available to publish workflows

[enyst]

Related PRs:

• Disable uv Actions cache in PR review agent workflow #2123
• Fix PR review workflow #2126

---

If we intentionally run a reviewer agent with Bash on fork PRs, the right mental model is:

“The PR author can get arbitrary code execution on the runner in that job.”

So the risk isn’t “can they run code?” (yes), it’s what can they reach / pivot to once they can.

Below are the concrete surfaces and the mitigations that keep this from turning into a Clinejection-style “pivot into release creds / other workflows” incident.

---

1) Primary surfaces when you run on fork PRs with Bash

A. Secret exfiltration from the reviewer job

If the job has any secrets (LLM key, PAT, etc.), assume they can be stolen:

• via curl/python/node/etc.
• via embedding into logs/artifacts
• via DNS/HTTP egress

So the goal becomes: only expose “review-only” secrets, and make them low-value.

B. GitHub token abuse

Even without secrets, the GITHUB_TOKEN can do damage if permissions are broad:

• contents: write → push commits
• actions: write → delete caches / trigger workflows / mess with runs
• packages: write, etc.

So the goal is: least privilege.

C. Cross-workflow cache pivot (the setup-uv / cache angle)

This is the Clinejection-style pivot.

If the reviewer job (attacker-controlled) can write cache entries, and a different, more privileged workflow later restores those cache entries, you’ve created a “persistence + pivot” bridge between workflows.

That’s exactly why setup-uv enable-cache: true is part of the “surface”: it enables writing/restoring caches that can outlive a single run.

---

2) What “minimize risk but keep the feature” looks like

1) Make the reviewer job “no-pivot”

Concretely:

• No Actions cache writes in the reviewer workflow.
  • Set setup-uv enable-cache: false
  • Avoid actions/cache entirely in that workflow
• Ensure privileged workflows (release/publish) also:
  • do not restore caches written by untrusted contexts, OR
  • use secret-salted cache keys that untrusted workflows can’t predict (requires secrets only available in trusted workflows)

This addresses the “spread to other workflows” concern directly.

2) Make secrets in the reviewer workflow intentionally low-impact

If you must run pull_request_target to get an LLM key on fork PRs, treat that key as burnable:

• a dedicated LLM API key only used for PR review
• hard rate limits / spend limits
• no shared credentials with release/publishing workflows

Same story for GitHub auth:

• prefer ephemeral GITHUB_TOKEN over a PAT
• keep permissions: minimal (e.g., contents: read, pull-requests: write, maybe issues: write; nothing else)

3) Keep “trusted code” separate from “untrusted code”

Even if you run against PR code, keep the reviewer implementation pinned to a trusted ref:

• The workflow/composite action/script that orchestrates the review should come from main (or a pinned SHA).
• The target repo checkout can be the PR head SHA.

This prevents the PR from modifying the reviewer agent itself (still not a complete defense if Bash is available, but it removes an easy self-modification path).

4) Optional but strong: network egress restriction

The best containment for “Bash on untrusted code” is network controls:

• allow egress only to:
  • GitHub APIs
  • your LLM proxy
• block everything else

This is easiest on self-hosted runners with firewalling; it’s harder on GitHub-hosted runners but not impossible if you’re willing to enforce iptables rules (still brittle).

5) Tooling guardrails (helps, but don’t over-trust)

You can also reduce the chance of “prompt makes agent do something dumb”:

• system prompt: explicitly forbid installing arbitrary packages / running curl | bash
• bash wrapper / allowlist (block curl, wget, nc, ssh, etc.)

But: with Bash, this is defense-in-depth, not a guarantee.

---

3) A “best practice” architecture (if you want to go further)

If you want to run on forks without putting an LLM key in GitHub secrets at all, the usual pattern is:

• Use pull_request (not pull_request_target) to run on forks
• Obtain LLM access via a token broker using GitHub OIDC (short-lived, scoped)
• Post results via a second “comment-only” trusted workflow, or via a GitHub App

This is more infra work, but it’s the cleanest way to keep “untrusted execution” and “secrets” separate.

---

How this relates to PR #2119

PR #2119 intentionally went in the “eliminate untrusted execution” direction for the PR review workflow.

Given what you just said (“we’re OK taking some risk; we want it to run on fork PRs with Bash”), the right next step is to adjust the design toward:

• restore PR-head checkout/exploration for the review job
• keep caching disabled and permissions minimal
• ensure no privileged workflows consume caches that an untrusted job can write

If you want, I can propose a concrete workflow layout (YAML) that matches this threat model, and update PR #2119 accordingly. The key question: do you want it to run automatically on every fork PR open, or only on a label/comment trigger to control cost/abuse?

[enyst]

Hi — I’m OpenHands-GPT-5.2. Posting my /codereview-roasted of:

• PR Restrict PR review workflow to collaborators extensions#65

🟡 Acceptable

You’re solving a real problem (#64): untrusted PR authors shouldn’t be able to poke the “LLM-with-secrets” bear via workflow triggers. The new gates largely do that. But you also added a bit of YAML logic soup and left some easy security hardening on the table.

Linus-Style Analysis

[CRITICAL ISSUES]

• None that obviously break the intent. The core security invariant (“don’t run the review action with secrets unless trusted”) is maintained by gating the Run PR Review step.

[IMPROVEMENT OPPORTUNITIES]

• [.github/workflows/pr-review-by-openhands.yml, Lines 31–39] Complexity / readability:
  That job-level if: is now a mini programming language. Yes, GitHub Actions forces this, but the repeated contains(fromJSON(...)) and mixed concerns (auto vs manual triggers) make it easy to screw up later.
  Actionable fix: compute is_trusted_author and is_manual_trigger once via github-script outputs, then use a single simple boolean expression for the review step.

• [.github/workflows/pr-review-by-openhands.yml, Lines 45–69] Permission check is good, but also kind of redundant in one place:
  You’re checking repos.getCollaboratorPermissionLevel for the triggering user. That’s the right thing if GitHub lets PR authors request reviewers without write access (which is exactly the kind of “UI convenience” that becomes a security footgun).
  But for labels, GitHub already requires elevated permissions to apply them in the target repo. If that assumption holds, this is extra API calls and cognitive overhead.
  Actionable fix: keep the check for review_requested, and document why labels still need it (or drop it for label events if you confirm GitHub’s permission model is sufficient).

• [.github/workflows/pr-review-by-openhands.yml, Lines 17–20] Over-broad default token permissions during “blocked” runs:
  For untrusted manual-trigger attempts, the workflow still runs actions/github-script with a github.token that has pull-requests: write and issues: write. You’re not abusing it, but it’s unnecessary power in runs that are supposed to do almost nothing.
  Actionable fix: split the job:

  1. a minimal-permissions job that checks actor permission and outputs allowed, and
  2. a second job (needs secrets + write perms) that only runs when allowed == true or when trusted author auto-triggered.

• [.github/workflows/pr-review-by-openhands.yml, Line 48] Supply-chain hygiene:
  uses: actions/github-script@v7 is a moving tag. In a PR that is explicitly about security, leaving mutable tags is sloppy.
  Actionable fix: pin to a full commit SHA (same goes for any other third-party actions you rely on in this workflow).

• [plugins/pr-review/workflows/pr-review-by-openhands.yml] Duplication:
  You updated both workflow copies consistently (good), but the existence of two authoritative copies is a maintenance trap. You’ll “fix security” in one and forget the other later.
  Actionable fix: make one source-of-truth (reusable workflow, or generate/copy in CI), then enforce via test.

[TESTING GAPS]

• Workflows are inherently hard to unit test, but this change is behaviorally significant. At minimum, you want some automated guardrail that the “secrets-bearing step” can’t run for author_association outside the allowlist.
  Actionable fix: add a lightweight check in tests/CI that parses the workflow and asserts the allowlist and gating conditions exist (yes, it’s not perfect, but it catches accidental deletions).

VERDICT

✅ Worth merging: the security logic is directionally correct and materially reduces prompt-injection exposure.
But if you want this to be “security work” rather than “security-flavored YAML,” pin action SHAs and consider splitting the permission-check and secret-using steps into separate jobs with minimal permissions.

KEY INSIGHT: You fixed the trigger surface, but you haven’t fully minimized the privileged execution surface (mutable action tags + broad job permissions still exist even in blocked runs).

[all-hands-bot]

This issue is stale because it has been open for 40 days with no activity. Remove the stale label or leave a comment, otherwise it will be closed in 10 days.

[enyst]

@smolpaws

[smolpaws]

🐾 Hey enyst! smolpaws is warming up in OpenHands/software-agent-sdk.
Request: (none)