Dependent repositories exposed: ~15,000 (Source: Socket, citing GitHub's dependency graph for actions-cool/issues-helper (September 2026))
Two third-party GitHub Actions that GitHub disabled in May for shipping malware were made accessible again in September without their malicious release tags being cleaned up first, exposing thousands of downstream projects to a payload that had sat dormant for four months. Security research firm Socket reported the reopening in a September 25, 2026 update to its ongoing coverage of the incident.
A dependency nobody was watching
Both tools handle small, repetitive chores that maintainers set up once and rarely revisit: flagging issues that have gone quiet, reviewing freshly opened ones, or keeping a single bot-authored comment current. Neither ships as part of a product; each is the kind of dependency that fades into the background of a repository's workflow files. Attackers redirected what the release tags of both actions pointed to during the May 2026 Mini Shai-Hulud campaign. GitHub took the repositories offline on May 19, 2026, a day after that change was made, which cut off any workflow trying to pull either action.
Disabling the repository didn't touch the malware
Containment held until September 16, 2026, when both repositories became reachable again. According to Socket, the malicious release tags were never reset before access was restored — a reference such as v2.2.1 still pointed to the same commit introduced in May. Any workflow calling either action by version tag, rather than a pinned commit hash, resumed downloading and running that code on its next scheduled or event-triggered run, with no further action required from the attacker.
Socket's review of run histories shows the shift directly: workflows that had been failing within seconds while the repositories were disabled suddenly began succeeding and running for several minutes. The extra minutes were spent installing a separate JavaScript runtime and executing an obfuscated script with the workflow's access token and secrets, before the action quietly resumed its normal behavior so the job still appeared to succeed.
A short window, no new attack
Socket disclosed that both repositories were disabled a second time on September 25, 2026, after the exposure was reported — a nine-day window in which the same May payload could execute anywhere the actions were still referenced by tag. Socket said it could not determine why the repositories were reopened, and has not ruled out a request from their legitimate maintainers.
What to ask your engineering team
This incident required no new exploit — only a platform decision to restore access to code nobody had rewritten. For an organization that runs any CI/CD pipeline on GitHub, the exposure question isn't limited to these two actions. Budget-holders should ask: Do our workflows reference third-party GitHub Actions by version tag or by pinned commit SHA, and how would we know if that changed? If a workflow ran with a tag reference to either compromised action on or after September 16, 2026, have we rotated every secret and token that workflow could reach? Who owns the inventory of third-party actions running with our repository secrets, and how often is it reviewed? And do we have alerting on workflow runs that suddenly change duration or behavior without a corresponding code change on our side?
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.
