Repositories listed as depending on issues-helper: About 15,000 (Source: Socket, citing GitHub's dependency graph, as reported by BleepingComputer (September 27, 2026))
A removed dependency came back with its payload
Two third-party GitHub Actions compromised in May were re-enabled by their maintainer and stayed accessible for more than a week while still pointing to malicious code. BleepingComputer reported the finding on September 27, 2026, citing research from application security company Socket. The actions are actions-cool/issues-helper and actions-cool/maintain-one-comment. Both were compromised on May 18 in the Mini Shai-Hulud campaign. GitHub's security team then removed them, which stopped downstream workflows from downloading the malware.
According to Socket, from September 16 through September 25 both actions became active again under the same release tags. Socket explained: "Their release tags were not cleaned up first. They still point to the malicious content introduced on May 18, so any workflow that references either action by a version tag resumed downloading and executing the payload on its next run." On September 25, Socket found both actions disabled again. Workflows that reference them now fail instead of running the payload. It is unclear why the repositories were re-enabled before cleanup.
What the findings do and do not establish
The 15,000 figure comes from GitHub's dependency graph. Socket says it does not mean all of those repositories were compromised. Socket also has not established how many dependents reference either action by mutable tag rather than a pinned commit. That number decides how many organisations actually ran the payload. Socket notes that the affected actions run almost daily because they support issue housekeeping, so a workflow that referenced them by tag would have had frequent opportunities to execute.
The exposure began on September 16 between 11:09 and 18:16 GMT+2. This is one incident. It shows what can happen when a platform-level removal is reversed by a maintainer without the tags being cleaned. The reporting does not support a broader pattern.
Why this matters to an organisation
The May 2026 campaign infected npm packages with malware that BleepingComputer says targets developers' tokens, credentials and CI/CD secrets. Workflows that pull in third-party actions run with access to those secrets. In this case the control that protected downstream users was GitHub's removal of the repositories. That control was outside the consuming organisation's hands, and it was undone by the maintainer. A workflow pinned to a version tag had no protection once the repositories returned.
Socket's recommended response has four steps: find references to both actions, remove them or pin a verified clean commit, review workflow runs since September 16, and rotate secrets accessible to any workflow that ran an affected tag.
What to ask your team
First, do any of our repositories reference actions-cool/issues-helper or actions-cool/maintain-one-comment, and can we show the search that answered that? Second, which workflow runs executed between September 16 and September 25, and which secrets were available to them? Have those secrets been rotated? Third, across all third-party actions we use, how many are referenced by version tag and how many by pinned commit? Socket has not established this for these two actions, so only an internal inventory can answer it. Fourth, who is notified when a third-party action we depend on is removed, and who reviews it if it is later restored?
