Mini Shai-Hulud GitHub Actions Re-Enablement: Check Tag-Based Runs Since September 16

By AiCybr Editorial · Published September 26, 2026

Two previously compromised GitHub Actions, actions-cool/issues-helper and actions-cool/maintain-one-comment, became reachable again on September 16, 2026 while their release tags still resolved to malicious code introduced during the May Mini Shai-Hulud campaign. Socket reported the re-exposure on September 24 and updated its research on September 25 after GitHub disabled both repositories again.

The September event matters to repositories that referenced either action by a mutable tag. Socket says those workflows could resume downloading and executing the compromised action when a trigger fired after September 16. Workflows pinned to a verified clean full commit SHA from before the May 18 compromise were outside that tag-reenablement path.

GitHub's current security guidance recommends pinning third-party actions to a full-length commit SHA, which GitHub describes as the only way to consume an action as an immutable release. Teams that ran either affected action by tag during the September exposure window should treat accessible workflow credentials as potentially exposed and review the affected repositories accordingly.

Incident at a glance

Which workflows need review

Start by searching workflow files for these two strings:

actions-cool/issues-helper@
actions-cool/maintain-one-comment@

Socket advises treating tag-based references to either action as affected for the September re-exposure. Its example includes actions-cool/[email protected], and the research states that all release tags it checked resolved to malicious content at publication time.

The relevant September review window begins September 16, 2026, when Socket observed the repositories becoming accessible again. A workflow still containing one of the affected tag references could execute the action the next time its configured event or schedule triggered.

A repository containing the dependency is only the first filter. Review whether the affected workflow actually ran after September 16, what permissions its GITHUB_TOKEN held, which repository or environment secrets were available to the job, and whether the run produced artifacts or deployment output that subsequently moved downstream.

Why the tags became dangerous again

The two actions were compromised in May and disabled by GitHub on May 19. That disablement prevented downstream workflows from downloading them, causing affected jobs to fail before the action could run.

Socket found that the repositories became accessible again on September 16 while the existing release tags still pointed to the malicious May 18 content. No new workflow-file change was required in downstream repositories: a workflow that retained a mutable tag reference could fetch the action again once the upstream repository was reachable.

GitHub disabled both repositories again by September 25, according to Socket's update. New attempts to fetch the disabled actions now fail during job setup. Credentials and artifacts from workflows that ran during the exposure window still require incident review.

Response checklist for affected repositories

1. Inventory both action names

Search .github/workflows/ across repositories and organization-level code search for both affected actions-cool references. Record the exact ref after @ so tag references can be separated from full-SHA pins.

2. Review runs from September 16 onward

For repositories with affected tag references, inspect workflow history beginning September 16. Socket recommends looking for jobs that began succeeding after a period of setup failures and for unexplained changes in run duration.

Map each successful affected run to the credentials and permissions available to that job. Include repository and environment secrets, cloud credentials, package-publishing credentials and the effective GITHUB_TOKEN permissions where applicable.

3. Rotate credentials that were reachable

Rotate credentials accessible to an affected run instead of limiting the response to editing the workflow reference. Prioritize credentials that can publish packages, deploy workloads, write to repositories or access cloud infrastructure.

Review the effective scope of the workflow's GITHUB_TOKEN as part of the same exercise. GitHub recommends explicitly granting minimum required token permissions in workflows to reduce the impact of a compromised third-party action.

4. Inspect repository and release history

Review repository history after September 16 for unexpected commits or workflow changes. For jobs involved in builds, releases or deployments, identify artifacts produced by affected runs and determine whether they require replacement or additional validation.

5. Remove or replace the disabled action

Both affected upstream repositories are disabled again, so a workflow cannot currently remediate the dependency simply by changing its reference to an older upstream commit SHA: GitHub still needs to fetch that commit from the disabled repository. Remove the affected action, replace it with a maintained alternative, or vendor a verified clean implementation when the workflow must continue operating.

If an affected upstream repository becomes reachable again, a known-clean full commit SHA verified to predate the May 18 compromise can become an option after verifying the commit belongs to the intended repository. GitHub's secure-use documentation recommends full-length SHA pinning for third-party actions because tags can be moved or deleted. Repository and organization policies can also require actions to use full-length commit SHAs.

Tag pinning versus SHA pinning

A version tag such as @v2 or @v2.2.1 is a Git reference whose target can change. That flexibility is useful for release maintenance, and it means the workflow trusts the current upstream tag target whenever a run resolves the action.

A full commit SHA identifies one Git object. GitHub's security documentation calls full-SHA pinning the only way to use an action as an immutable release and recommends verifying that the selected SHA comes from the intended action repository. SHA pinning protects against a moved tag; it does not make a disabled upstream repository fetchable.

Organizations that want enforcement can enable GitHub's Require actions to be pinned to a full-length commit SHA policy at repository or organization level. This converts SHA pinning from a review convention into a platform policy for actions covered by the setting.

How this differs from the broader Mini Shai-Hulud campaign

The September incident is a re-exposure of two GitHub Action repositories compromised in May. Socket attributes the malicious content to the Mini Shai-Hulud activity cluster and reports that the September execution path came from old malicious tags becoming downloadable again.

That scope is operationally distinct from separate Mini Shai-Hulud and related Miasma waves involving npm, PyPI and other developer ecosystems. Teams investigating these two actions should use the September 16 re-enable date and the two actions-cool repository names as the immediate triage boundary, then expand investigation when their telemetry shows related compromise indicators.

Bottom line

Repositories that referenced actions-cool/issues-helper or actions-cool/maintain-one-comment by tag should review workflow executions from September 16 through the second GitHub disablement reported on September 25. Successful affected runs warrant credential-scope review, rotation of reachable secrets, repository-history inspection and validation of downstream artifacts.

For these two currently disabled repositories, remove or replace the dependency before restoring the workflow. For reachable third-party actions generally, use verified full-length commit SHAs, minimize workflow token permissions and enforce SHA-pinning policy where the operational model allows it.

Sources

• Socket — Re-Enabled GitHub Actions Expose Thousands of Repositories to Mini Shai-Hulud: https://socket.dev/blog/mini-shai-hulud-actions
• GitHub Docs — Secure use reference for GitHub Actions: https://docs.github.com/en/actions/reference/security/secure-use
• GitHub Docs — Managing GitHub Actions settings for a repository: https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository
• The Hacker News — Compromised GitHub Actions Came Back Online and Resumed Executing Mini Shai-Hulud Malware: https://thehackernews.com/2026/09/compromised-github-actions-came-back.html