mirror of
https://github.com/Jeuners/ECC.git
synced 2026-09-09 15:02:30 +02:00
cdbc925d89
The `pull_request_target` rule's `expressionPattern` matches only
the canonical `github.event.pull_request.head.{ref,sha,repo.full_name}`
interpolations. It does not match the second canonical form of
the same exploit — fetching `refs/pull/<N>/{head,merge}` directly:
- uses: actions/checkout@v4
with:
ref: refs/pull/${{ github.event.pull_request.number }}/merge
The merge-ref variant is what GitHub's own security guidance calls
out as the highest-severity privilege-escalation pattern under
`pull_request_target`: it materialises the PR's merge commit
(attacker code spliced with base), executes inside a workflow that
has full repo-scoped tokens, and gives the attacker the chance to
exfiltrate secrets or push to default branches. `refs/pull/N/head`
is functionally equivalent — same source, same trust boundary.
Reproduced on `main` before this commit:
$ cat /tmp/bad.yml
name: bad
on: { pull_request_target: { types: [opened] } }
permissions: { contents: read }
jobs:
do:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
ref: refs/pull/${{ github.event.pull_request.number }}/merge
persist-credentials: false
- run: npm ci --ignore-scripts
$ ECC_WORKFLOWS_DIR=/tmp node scripts/ci/validate-workflow-security.js
Validated workflow security for 1 workflow files
$ echo $?
0
Expected: violation flagging the refs/pull checkout under pull_request_target.
Actual: passes silently.
Fix: add a `refPattern` to the `pull_request_target` rule:
/^\s*ref:\s*['"]?[^'"\n]*refs\/(?:remotes\/)?pull\/[^'"\n\s]+/m
and apply it per checkout step inside the existing
event-gated loop. The pattern matches the ref VALUE so it catches
all interpolation shapes — `refs/pull/123/head`,
`refs/pull/${{ github.event.pull_request.number }}/merge`,
`${{ env.FOO }}/refs/pull/N/head` — without enumerating the
possible interpolations themselves.
Scoping: the rule is already gated on the workflow containing
`pull_request_target:`, so non-privileged `pull_request` workflows
that legitimately check out a PR ref are not affected.
After this commit the reproduction above exits 1 with:
ERROR: bad.yml:10 - pull_request_target must not checkout an untrusted pull_request head ref/repository
Three new regression tests in `tests/ci/validate-workflow-security.test.js`:
- rejects pull_request_target + refs/pull/<N>/merge
- rejects pull_request_target + hardcoded refs/pull/<N>/head
- allows pull_request_target with no `with.ref:` (base-ref checkout —
the safe pattern from GitHub's own guidance)
Test count: 17 → 20 in this file; full `yarn test` still green.
Together with the previous commit, this closes the two
independent `validate-workflow-security.js` bypasses I found.
|
||
|---|---|---|
| .. | ||
| ci | ||
| codemaps | ||
| codex | ||
| codex-git-hooks | ||
| hooks | ||
| lib | ||
| auto-update.js | ||
| build-opencode.js | ||
| catalog.js | ||
| claw.js | ||
| consult.js | ||
| discussion-audit.js | ||
| doctor.js | ||
| ecc.js | ||
| gan-harness.sh | ||
| gemini-adapt-agents.js | ||
| harness-adapter-compliance.js | ||
| harness-audit.js | ||
| install-apply.js | ||
| install-plan.js | ||
| list-installed.js | ||
| loop-status.js | ||
| observability-readiness.js | ||
| operator-readiness-dashboard.js | ||
| orchestrate-codex-worker.sh | ||
| orchestrate-worktrees.js | ||
| orchestration-status.js | ||
| platform-audit.js | ||
| preview-pack-smoke.js | ||
| release.sh | ||
| repair.js | ||
| session-inspect.js | ||
| sessions-cli.js | ||
| setup-package-manager.js | ||
| skill-create-output.js | ||
| skills-health.js | ||
| status.js | ||
| sync-ecc-to-codex.sh | ||
| uninstall.js | ||
| work-items.js | ||