From f4542d960511368eaeab50f68580a89aa13903e6 Mon Sep 17 00:00:00 2001 From: mubashir1osmani Date: Wed, 26 Aug 2026 15:26:02 -0400 Subject: [PATCH] fix(ci): pin the Bun runtime instead of tracking latest The setup step ran `bun-version: latest`, carried over from the upstream layout, and the step after it holds an issues: write token. A compromised Bun release would have executed privileged in that job and could rewrite or close issues. Pinned to 1.4.0, the release the passing runs already resolved to. setup-bun takes no checksum input, so pinning the action by sha and the runtime by exact version is as far as this can be hardened without hand-rolling the download. --- .github/workflows/auto-close-duplicates.yml | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/.github/workflows/auto-close-duplicates.yml b/.github/workflows/auto-close-duplicates.yml index 886aeaaa8e6..ff3b5eff7c2 100644 --- a/.github/workflows/auto-close-duplicates.yml +++ b/.github/workflows/auto-close-duplicates.yml @@ -23,7 +23,10 @@ jobs: - name: Setup Bun uses: oven-sh/setup-bun@0c5077e51419868618aeaa5fe8019c62421857d6 # v2.2.0 (sha-pinned) with: - bun-version: latest + # Exact version, never latest: the next step holds an issues: write token, + # so a compromised Bun release would run privileged here. setup-bun exposes + # no checksum input, so pinning the action and the version is the ceiling. + bun-version: "1.4.0" - name: Auto-close duplicate issues run: bun run scripts/auto-close-duplicates.ts