- Socket reported on September 24 that two GitHub Actions disabled in May after the Mini Shai-Hulud compromise became downloadable again on September 16, with their malicious release tags untouched.
- Workflows that call either action by version tag would have fetched the malicious code; Socket has not established how many of the roughly 15,000 dependents use a tag, so actual exposure is unknown.
- Check whether any workflow ran either action by tag since September 16, replace any credentials it could reach, and pin outside actions to commits verified clean.
GitHub's security team disabled two GitHub Actions on May 19, 2026, after they were compromised in the Mini Shai-Hulud campaign. On September 16 they became downloadable again, and their malicious release tags had not been touched, Socket reported on September 24. A workflow that references either action by version tag would have fetched the May payload on its next run. Socket has not established how many dependents use a tag, so the number of projects that actually executed the code is unknown.
Chore automation with access to secrets
Both actions, actions-cool/issues-helper and actions-cool/maintain-one-comment, are repository housekeeping tools. They tidy stale tickets, screen new ones and refresh a bot's comment. Socket observes that they are not part of anyone's shipped product and that many maintainers have probably forgotten them. Yet they execute with the workflow's token and secrets, typically on a daily timer or when an issue or pull request is opened, and no person reviews each run. Socket adds that any GitHub user able to open an issue on a public repository can set off an issue-triggered workflow.
That is a count of dependents, not of exposed repositories. Only workflows that reference an action by tag were affected, and maintain-one-comment adds dependents that Socket did not quantify.
Disabling contained the code but did not clean it
In May, GitHub chose to switch the repositories off rather than rewrite or delete the tags. While they were off, workflows failed during job setup, before any action code executed. That was the whole protection, and it held only while the repositories stayed offline. From run histories, Socket places the return of access on September 16 in a window from 11:09 to 18:16 GMT+2 and cannot narrow it further.
Run #1849 stopped with "Repository access blocked". Run #1850 ran for over eleven minutes, and its log lists downloads of [email protected], a Bun runtime setup action and a further issues-helper commit. Socket's interpretation is that a housekeeping tool has little reason to fetch a JavaScript runtime and work for minutes, and that the layout suits a wrapper that executes malicious code and then passes control to the genuine logic, leaving the job looking successful. Per Socket, code running in that job can reach its GITHUB_TOKEN and any secrets the workflow exposes. The daily "Issue Inactive" workflow in Moonofweisheng/wot-design-uni shows the same shift: failures of 8 and 5 seconds on September 14 and 15, then a 9 minute 34 second success on September 16.
What Socket has and has not established
Why access returned is not known. Socket names a request from the legitimate maintainers as one possibility but has not confirmed it. Its September 25 update says both repositories are disabled again. Socket's estimate, which it has not counted, is that most exposed repositories probably ran the payload within a day of reopening.
What this means for a budget signer
Socket stresses that no new exploit, infrastructure or compromise was needed here. Restoring access to old, unrewritten code was enough. For a budget signer, two points follow from that. First, a platform's containment is temporary. Socket says disabling a repository leaves the malicious content in place, and when access returns, every consumer that relied on the block is exposed again without notice. Socket's advice to platforms is to confirm that tags, releases and default branches are clean before reopening. Consumers cannot influence that decision. Second, small third-party automations in CI can hold access to secrets while nobody is watching them, and Socket suggests some maintainers had forgotten they were there. That gap belongs to the organisation, not the platform.
Questions for your engineering team
First, which third-party actions do our workflows call, by tag or by full commit SHA, and who would learn if an upstream repository changed status? Second, did any workflow run either action by tag from September 16, 2026 onward, and if so, which credentials could that job reach, have they been replaced, and what was its GITHUB_TOKEN permitted to do? Third, has anyone looked in run histories for jobs that began succeeding after repeated setup failures, or whose duration jumped from seconds to minutes? Fourth, who is named as owner of the list of outside actions that run alongside our secrets? Finally, where we pin, does each pin trace to a release verified as older than May 18, 2026? Socket cautions that a pin protects only when the commit itself is clean.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Socket.
