fix(sop-tier-check): use pull_request_target — pull_request leaks token
Fans the security fix from internal#116 (cce89067) to molecule-core. Same rationale: pull_request loads workflow from PR HEAD, allowing any write-access contributor to rewrite the workflow file in their PR and exfiltrate SOP_TIER_CHECK_TOKEN. pull_request_target loads from base (main), neutralising the attack. Verified post-merge on internal: synthetic PR rewriting the workflow to print the token did NOT execute the modified version — main's pull_request_target version ran instead. ATTACK_PROBE never fired. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
parent
a50cda1a85
commit
5fe335ffae
@ -31,8 +31,22 @@
|
||||
|
||||
name: sop-tier-check
|
||||
|
||||
# SECURITY: triggers MUST use `pull_request_target`, not `pull_request`.
|
||||
# `pull_request_target` loads the workflow definition from the BASE
|
||||
# branch (i.e. `main`), not the PR's HEAD. With `pull_request`, anyone
|
||||
# with write access to a feature branch could rewrite this file in
|
||||
# their PR to dump SOP_TIER_CHECK_TOKEN (org-read scope) to logs and
|
||||
# exfiltrate it. Verified 2026-05-09 against Gitea 1.22.6 —
|
||||
# `pull_request_target` (added in Gitea 1.21 via go-gitea/gitea#25229)
|
||||
# is the documented mitigation.
|
||||
#
|
||||
# This workflow does NOT call `actions/checkout`, so no untrusted code
|
||||
# is ever executed in the runner — we only HTTP-call the Gitea API. If
|
||||
# a future change adds a checkout step, it MUST pin to
|
||||
# `${{ github.event.pull_request.base.sha }}` (NOT `head.sha`) to keep
|
||||
# the trust boundary.
|
||||
on:
|
||||
pull_request:
|
||||
pull_request_target:
|
||||
types: [opened, edited, synchronize, reopened, labeled, unlabeled]
|
||||
pull_request_review:
|
||||
types: [submitted, dismissed, edited]
|
||||
|
||||
Loading…
Reference in New Issue
Block a user