Two GitHub Actions of actions- cool committed in May and reactivated in September

Two public actions by GitHub Actions held by the actions-cool project - actions-cool / issues-helper and actions-cool / maintain-one-comment- were reactivated on 16 September 2026 and, after that, GitHub has redisabled them. It is confirmed that these actions had been committed on May 18, 2026 to execute malicious code intended to extract credentials from the CI / CD channels that invoked them and to send these data to a server controlled by the attackers; the activity was publicly associated with the threat cluster known as Mini Shai-Hulud. According to the research published by the firm Socket and his team's statements, the tags that pointed to the malicious code were never removed, so the only condition necessary to reactivate the threat was for the repositories to be reaccessible publicly.

Technically, the vector exploited here does not require to publish a new release or compromise another account: many GitHub Actions workflows refer to these actions by means of mutable references (e.g., tags like @ v2.2.1). When a mutable tag was pointed in May towards a commit that injected a payload - capable of reading and exfiltering secrets of the environment or context of the runner - any workflow that uses that tag download and runs that content in running time. Socket has also indicated that exfiltration reused a previously observed domain in the ecosystem incident @ antv (t.m-kosche [.] com), which allowed to correlate both campaigns with Mini Shai-Hulud. This re-use of infrastructure is a useful technical indicator for attribution and was a key factor in identifying the connection between Npm package commitments and stock abuse in GitHub.

Those affected are, first, the holders and users of repositories that incorporate these actions without setting them to a specific SHA commission prior to May 18. In practice this includes projects that automate issues closure, maintenance of bot comments or periodic checks, because such workflows are often run (e.g. on: schedule or on: issues / pull _ request). Socket estimates that most of the repositories that depended on these actions were able to execute the payload within one day of reactivation, given the usual execution pattern, although that point is a projection based on how these workflows are typically configured and not the verification of each individual repository.

The important technical consequences are several and concrete: exposure of tokens and secrets stored as environment variables in actions executions may allow an attacker to scale privileges, access other repositories, publish malicious packages in records with stolen credentials, or manipulate delivery pipelines. In addition, as a unit in the development supply chain, the silent execution of the payload in multiple projects multiplies the risk without requiring new vulnerabilities or additional infrastructure from the attacker - it is enough that the malicious code remains available under the reference that workflows consume.

confirmed facts: the initial commitments of 18 May 2026, the reactivation of access between 11: 09 and 18: 16 (GMT + 2) of 16 September 2026, the observation of labels that continued to point to malicious content, the identification of the exfiltration domain and the subsequent intervention of GitHub to disable the repos. Reasonable estimates: the speed with which most affected repositories could have executed the payload after reactivation, based on typical execution patterns. Still uncertain information: the root cause of why GitHub again allowed access to these repositories in September and whether there was a human intervention, an automated error or an administrative procedure that reversed the prior suspension.

What a development team or repository manager should do right now: locate all references to the two actions concerned and treat the reference actions-cool / issues-helper @ v2.2.1 as committed; eliminate this dependence or replace it with a known and clean SHA commission that is prior to 18 May 2026; immediately rotate all secrets and tokens that may have been available in executions that used these actions; review the history of workflow executions to detect successful executions after the reactivation or for unusually short periods in which the jobs had previously failed; and audit the repository's history in search of unexpected commitments after 16 September 2026. These recommendations are in line with mitigation practices against supply chain risks and the public warnings of researchers; GitHub maintains a guide on security hardening for Actions that includes the recommendation to use immutable references (SHA) to avoid exactly this type of reactivations: https: / / docs.github.com / en / actions / security-guides / security-hardening-for-github-actions.

Specific and priority technical measures: paint all the units of shares to your complete SHA commission (not to mutable tags), invalidate and rotate any exposed secrets (personal tokens, repository or organizational secrets) and review the permits assigned to the tokens to apply the principle of minor privilege. In addition, it is appropriate to enable organizational controls such as the manual review of external actions, to allow only actions audited from the Market or to restrict the execution of actions to self-hosted runners with stricter security policies. To check the reputation and history of an action, teams can rely on external analysis and unit detection tools - Socket is one of the firms that has published details about this campaign and maintains technical information about the research on its website: https: / / socket.dev /.

Interpretation: This incident stresses that the security of the supply chain is not only dependent on preventing new malicious publications; it also requires monitoring how they refer to and invoke dependencies. A compromised mutable label can be contained and then inadvertently reactivated without the consumer changing their own workflow, which makes the practice of pinning to SHA no longer a theoretical recommendation to be an operational necessity.

Finally, what still needs to be clarified: GitHub has not made public why access to these repositories was restored and whether it will take measures to proactively notify the repositories that were dependent on them. Organizations should assume that uncertainty persists and act as if any action referred to by mutable and potentially affected tag was insecure until proven otherwise through internal audit. The error in this matter is not to wait for GitHub to issue a statement, but not to verify the integrity of the units on its own and not to have a rapid response process for the rotation of credentials and the remediation of pipelines.