Tag-pinned workflows re-ran Mini Shai-Hulud after issues-helper was re-enabled

A workflow step that reads `uses: actions-cool/[email protected]` names a tag. On each run, the runner downloads the code behind that reference and reaches the step that executes it ^[17]. According to Socket, v2.2.1 and other release tags still pointed at the malicious commits from the May compromise the whole time the repository was disabled ^[3].

Nothing in the dependent repositories changed during the disable. Their Action downloads failed, and that failure was the only thing keeping the payload off their runners ^[4]. Once the upstream repositories came back ^[2], routine triggers such as cron schedules and issue creation fetched and checked out the malicious commits by themselves ^[5]. No one had to push a commit or move a tag ^[6].

In the runs Socket confirmed, a wrapper script installed the Bun JavaScript runtime and executed an obfuscated index.js, the Mini Shai-Hulud payload ^[7]. The payload goes after tokens and credentials available on the runner ^[9]. In job logs it appears as a Bun install or the line `bun run $GITHUB_ACTION_PATH/index.js` ^[8].

Those log lines are the evidence, because the other signals pointed the wrong way. Issue and comment jobs kept doing their intended work and finished with a green checkmark ^[10]. Workflows that had failed since the takedown started succeeding ^[10]. A red job that turns green with nobody touching it is usually a ticket that closes itself. Teams that review only their own repository diffs had nothing to look at, since the change lived upstream ^[6].

Socket's report is careful about scope. Execution is confirmed from public logs for issues-helper only, and Socket says that result cannot be generalized to all users of both Actions ^[11]. The roughly 15,000 figure on the dependency graph counts potential usage, not confirmed runs or data theft ^[12]. The window between re-enabling and the second takedown was nine days ^[19]. The report does not say who re-enabled the repositories or why.

What a run could reach depends on two separate boundaries ^[14]. One is the OS privileges of the job user on the runner. The other is the scope of the GITHUB_TOKEN plus any secrets passed to the workflow ^[14]. Stealing a credential needs only read access and a way to send it out. Tampering with source or publishing packages needs a stolen token with write permission ^[15]. A read-only token narrows what happens after the theft, and Socket is explicit that those theft conditions are no prerequisite for the code running at all ^[15].

Socket's fix is to drop the affected Action or pin it to a full 40-character commit SHA whose contents and provenance have been verified ^[16]. A SHA pin only helps if the commit behind it is clean. Socket lists a malicious commit SHA next to a malicious tag as the precondition for execution ^[17], so a SHA copied from a compromised release runs the same payload. I think verified SHA pins are the right tradeoff for third-party Actions that fire on issue events with repository tokens in scope. The price is that every upstream update becomes a manual bump someone has to read before merging.