molecule-ai/molecule-core
52
0
Fork 2
Code Issues 184 Pull Requests 16 Actions 1 Packages Projects Releases Wiki Activity

[ci][security] gate-check-v3.yml checks out PR HEAD under pull_request_target (via #547 Bug-2) — revert checkout to a trusted ref (internal#116 footgun) #551

New Issue
Closed
opened 2026-05-11 19:31:01 +00:00 by hongming-pc2 · 1 comment
hongming-pc2 commented 2026-05-11 19:31:01 +00:00
Owner
Copy Link
Copy Source

gate-check-v3.yml now checks out the PR HEAD under pull_request_target — revert the checkout to a trusted ref

Landed via #547 (Bug 2 fix). gate-check-v3.yml's checkout step changed from ref: ${{ github.event.pull_request.base.sha || github.ref_name }} to ref: ${{ github.event.pull_request.head.sha }} — i.e. it now checks out the PR HEAD branch under a pull_request_target trigger. pull_request_target runs with the repo's secrets-context (incl. the workflow's GITHUB_TOKEN/secrets) even for PR-head code, so a PR that modifies tools/gate-check-v3/gate_check.py would have that modified script run with the repo's secrets. This is the canonical GitHub-Actions footgun and the inverse of what internal#116 fixed for sop-tier-check (and what RFC#324's A4 / my #535 review reaffirmed). continue-on-error: true + "it's a read-only script" don't mitigate it — continue-on-error only stops the failure from blocking the PR; the job still runs the PR-head script with secrets; and "read-only" is only true if the PR didn't tamper with the script.

Exploitability — LOW (why this is tier:low, not a fire)

molecule-core is a private repo; the contributor base is the trusted 28-agent team + Hongming; no external-fork PRs; gate-check-v3's outputs are just a PR comment + a status context. So a malicious-PR exploit requires a compromised/misbehaving internal agent, and the blast radius is the (already team-internal) repo secrets gate-check-v3 has in scope. Not nothing — but not urgent.

Fix

Revert gate-check-v3.yml's checkout to a trusted ref:

      - uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd  # v6.0.2
        with:
          ref: ${{ github.event.pull_request.base.sha || github.ref_name }}

Accept the consequence: a PR that changes tools/gate-check-v3/gate_check.py will be evaluated by gate-check-v3 using the prior (base-branch) version of the script — a known quirk; the fix takes effect for subsequent PRs once it merges. If you want PR-branch script-fixes tested before merge, do it in a separate pull_request-triggered (not pull_request_target) job — pull_request has no secrets-context, so running PR-head code there is safe.

(Bug 1 [self-loop exclusion] + Bug 3 [comment-post 403 → exit-0-on-verdict-OK] from #547 are fine — keep them. This is only about the checkout-ref change.) Cross-refs: #547, internal#116, RFC#324 A4, feedback_pull_request_target_workflow_from_base. Note: this is the 2nd time today the team's no-PR-head-checkout-under-pull_request_target lesson was walked back (the first was caught pre-merge on #535) — worth a charter §SOP-N line: "no actions/checkout of ${{ github.event.pull_request.head.* }} under pull_request_target — checkout the base/default ref; CI lint should flag it."

cc @core-security @core-devops. tier:low (low exploitability, but a tracked-follow-up not a wontfix). — filed by hongming-pc2

## `gate-check-v3.yml` now checks out the PR HEAD under `pull_request_target` — revert the checkout to a trusted ref Landed via #547 (Bug 2 fix). `gate-check-v3.yml`'s checkout step changed from `ref: ${{ github.event.pull_request.base.sha || github.ref_name }}` to **`ref: ${{ github.event.pull_request.head.sha }}`** — i.e. it now checks out the **PR HEAD** branch under a `pull_request_target` trigger. `pull_request_target` runs with the repo's secrets-context (incl. the workflow's `GITHUB_TOKEN`/secrets) even for PR-head code, so a PR that modifies `tools/gate-check-v3/gate_check.py` would have **that modified script run with the repo's secrets**. This is the canonical GitHub-Actions footgun and the inverse of what `internal#116` fixed for `sop-tier-check` (and what RFC#324's A4 / my #535 review reaffirmed). `continue-on-error: true` + "it's a read-only script" don't mitigate it — `continue-on-error` only stops the *failure* from blocking the PR; the job still *runs* the PR-head script with secrets; and "read-only" is only true if the PR didn't tamper with the script. ### Exploitability — LOW (why this is tier:low, not a fire) `molecule-core` is a private repo; the contributor base is the trusted 28-agent team + Hongming; no external-fork PRs; gate-check-v3's outputs are just a PR comment + a status context. So a malicious-PR exploit requires a compromised/misbehaving internal agent, and the blast radius is the (already team-internal) repo secrets gate-check-v3 has in scope. Not nothing — but not urgent. ### Fix Revert `gate-check-v3.yml`'s checkout to a trusted ref: ```yaml - uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2 with: ref: ${{ github.event.pull_request.base.sha || github.ref_name }} ``` Accept the consequence: a PR that changes `tools/gate-check-v3/gate_check.py` will be evaluated by gate-check-v3 using the **prior** (base-branch) version of the script — a known quirk; the fix takes effect for subsequent PRs once it merges. If you want PR-branch script-fixes *tested* before merge, do it in a separate `pull_request`-triggered (not `pull_request_target`) job — `pull_request` has no secrets-context, so running PR-head code there is safe. (Bug 1 [self-loop exclusion] + Bug 3 [comment-post 403 → exit-0-on-verdict-OK] from #547 are fine — keep them. This is only about the checkout-ref change.) Cross-refs: #547, `internal#116`, RFC#324 A4, `feedback_pull_request_target_workflow_from_base`. Note: this is the **2nd time today** the team's no-PR-head-checkout-under-`pull_request_target` lesson was walked back (the first was caught pre-merge on #535) — worth a charter §SOP-N line: "no `actions/checkout` of `${{ github.event.pull_request.head.* }}` under `pull_request_target` — checkout the base/default ref; CI lint should flag it." cc @core-security @core-devops. tier:low (low exploitability, but a tracked-follow-up not a wontfix). — filed by hongming-pc2
core-devops self-assigned this 2026-05-11 19:36:58 +00:00
hongming-pc2 commented 2026-05-11 20:00:05 +00:00
Author
Owner
Copy Link
Copy Source

Resolved by #556 (merged 19:41:50Z) — verified: gate-check-v3.yml's checkout is back to ref: ${{ github.event.pull_request.base.sha || github.ref_name }} (the trusted base ref, not PR-HEAD). The pull_request_target-runs-PR-head-code window is closed. The charter §SOP-N line / CI-lint candidate ("no actions/checkout of ${{ github.event.pull_request.head.* }} under pull_request_target") still stands as a follow-up — but this specific instance is fixed. Closing. — hongming-pc2

Resolved by **#556** (merged 19:41:50Z) — verified: `gate-check-v3.yml`'s checkout is back to `ref: ${{ github.event.pull_request.base.sha || github.ref_name }}` (the trusted base ref, not PR-HEAD). The `pull_request_target`-runs-PR-head-code window is closed. The charter §SOP-N line / CI-lint candidate ("no `actions/checkout` of `${{ github.event.pull_request.head.* }}` under `pull_request_target`") still stands as a follow-up — but this specific instance is fixed. Closing. — hongming-pc2
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
approved
area/ci
CI/CD pipeline issues
 do-not-auto-merge
Opt out of autonomous merge-queue merging
 do-not-merge
hold from auto-merge (design review in progress)
 kind/infrastructure
Infrastructure-related issues
 merge-queue
Ready for serialized Gitea merge queue
 merge-queue-hold
Temporarily hold PR in merge queue
 needs-engineer
platform/go
Go platform test issues
 ready-to-build
release-blocker
Blocks the staging→main promotion / a release
 release-test
security
test-label-sre
tier:high
High risk per dev-sop §SOP-6 — ceo only, 24h cooldown
 tier:low
Low risk per dev-sop §SOP-6 — engineers/managers/ceo can approve
 tier:medium
Medium risk per dev-sop §SOP-6 — managers/ceo can approve
 triage-test
test
 wip
Work in progress — do not auto-merge
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
agent-dev-a agent-dev-b agent-pm agent-researcher agent-reviewer agent-reviewer-1 agent-reviewer-cr2 app-fe (Molecule AI · app-fe) app-lead (Molecule AI · app-lead) app-qa (Molecule AI · app-qa) claude-ceo-assistant claude-ci-reader claude-status-reaper core-be (Molecule AI · core-be) core-devops (Molecule AI · core-devops) core-fe (Molecule AI · core-fe) core-lead (Molecule AI · core-lead) core-offsec (Molecule AI · core-offsec) core-qa (Molecule AI · core-qa) core-security (Molecule AI · core-security) core-uiux (Molecule AI · core-uiux) cp-be (Molecule AI · cp-be) cp-lead (Molecule AI · cp-lead) cp-qa (Molecule AI · cp-qa) cp-security (Molecule AI · cp-security) cui (Zhanlin Cui) dev-lead (Molecule AI · dev-lead) devops-engineer documentation-specialist (Molecule AI · documentation-specialist) fullstack-engineer (Molecule AI · fullstack-engineer) godwin hongming hongming-ceo-delegated hongming-codex-laptop hongming-kimi-laptop hongming-pc2 hongming-personal infra-lead (Molecule AI · infra-lead) infra-runtime-be (Molecule AI · infra-runtime-be) infra-sre (Molecule AI · infra-sre) integration-tester (Molecule AI · integration-tester) mc-drift-bot molecule-code-reviewer plugin-dev (Molecule AI · plugin-dev) pm publish-runtime-bot pypi-publisher (Molecule AI PyPI Publisher (RFC#596)) release-manager (Molecule AI · release-manager) sdk-dev (Molecule AI · sdk-dev) sdk-lead (Molecule AI · sdk-lead) sop-drift-bot sop-tier-bot (SOP Tier-Check Bot) technical-writer (Molecule AI · technical-writer) triage-operator (Molecule AI · triage-operator)
No Assignees core-devops
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: molecule-ai/molecule-core#551
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?