Compromised GitHub Actions Resurface, Silently Resume Serving Malware

What happened

Two third-party GitHub Actions, actions-cool/issues-helper and actions-cool/maintain-one-comment, briefly came back online in mid-September and resumed serving a credential-stealing payload originally planted during the May 2026 "Mini Shai-Hulud" supply-chain campaign. Both repositories had been disabled by GitHub after that campaign compromised hundreds of npm packages and multiple GitHub Actions used to harvest developer tokens, credentials, and CI/CD secrets. According to researchers at Socket, the two repositories became accessible again between September 16 and September 25 without their existing release tags being cleaned up first — meaning the tags still pointed to the exact malicious commit introduced back in May. Any workflow referencing either action by its version tag (rather than a pinned commit hash) would have silently re-downloaded and executed that payload the next time it ran. GitHub disabled both repositories again on September 25 once the issue was identified, and it remains unclear why they were made accessible in the first place.

Who is affected

Any organization whose CI/CD workflows reference actions-cool/issues-helper or actions-cool/maintain-one-comment by a mutable version tag (for example, @v2.2.1) rather than a full commit SHA is potentially affected. Socket estimates that GitHub's own dependency graph lists roughly 15,000 repositories with a dependency relationship on issues-helper alone, though this figure does not mean all of them were compromised — actual impact depends on whether a given workflow actually executed during the exposure window and whether it referenced the action by tag or by pinned commit. Both actions are typically used for routine issue and comment housekeeping (auto-closing inactive issues, keeping a bot comment updated) and are commonly configured to run on a daily schedule or on every new issue/pull request, which increases the odds that an affected workflow executed at least once during the roughly nine-day exposure window.

Why it matters

This incident illustrates a supply-chain risk pattern distinct from the usual "newly compromised package" story: no new malicious code was published, no account was freshly hijacked, and no new infrastructure was stood up. The existing malicious commit simply became reachable again because the repository's access restriction was lifted without a corresponding cleanup of the tags pointing at it. For any workflow using mutable version tags instead of commit-SHA pinning, this means a previously contained compromise can be silently reactivated by an upstream change entirely outside the consuming organization's control — with no visible change to their own workflow files. This is a strong practical argument for commit-SHA pinning as a default practice for third-party GitHub Actions, not just as a response to a specific incident.

Technical details

• Original compromise date: May 18, 2026, as part of the broader Mini Shai-Hulud campaign that also affected 323 npm packages and 639 package versions.
• Re-exposure window: September 16, 2026 (between 11:09 and 18:16 GMT+2) through September 25, 2026, when GitHub disabled the repositories a second time.
• Mechanism: Release tags on both repositories were not invalidated or updated when the repositories regained public accessibility, so they continued to resolve to the malicious commit's index.js file.
• Payload behavior: Obfuscated code designed to harvest CI/CD secrets, developer tokens, and credentials from the environment of any workflow that executed it, exfiltrating them to an attacker-controlled domain linked to the broader Mini Shai-Hulud/@antv npm ecosystem incident.
• Scope caveat: The ~15,000 dependent-repository figure reflects GitHub's dependency graph for issues-helper and is not a confirmed compromise count; actual exposure depends on tag-vs-SHA referencing and execution timing during the window.
• Mitigation gap: Workflows that already pinned either action to a full commit SHA predating May 18, 2026 were not affected by the re-exposure.

Recommended actions

• Search your organization's workflows for any reference to actions-cool/issues-helper or actions-cool/maintain-one-comment, particularly by mutable tag (e.g., @v2.2.1 or similar version strings).
• Remove these actions where they are not essential, or replace tag references with a pinned, verified-clean commit SHA predating May 18, 2026.
• Review workflow run history for both repositories' consumers between September 16 and September 25, 2026, looking for unexpected successful runs following a period of failures (the repositories were disabled/re-enabled multiple times).
• Rotate all secrets accessible to any workflow that referenced either action during the exposure window, including CI/CD tokens, deployment credentials, and any cloud or registry API keys available to that pipeline.
• As a general practice going forward, pin all third-party GitHub Actions to a full commit SHA rather than a mutable tag or branch name, since tags can be repointed or reactivated without any visible change to your own repository.
• Audit repository and workflow history for unexpected commits or configuration changes following September 16, 2026, in case the payload executed and attempted further post-exploitation activity.

Sources

• https://thehackernews.com/2026/09/compromised-github-actions-came-back.html
• https://www.bleepingcomputer.com/news/security/github-actions-re-enabled-with-mini-shai-hulud-payload-still-active/