GitHub Actions Compromised in ‘Mini Shai-Hulud’ Attack Disabled Again Following Brief Reappearance

After the initial discovery in May, the affected repositories were disabled by GitHub to prevent further damage. However, the events of September 16, 2026, suggest that the containment was only temporary and lacked a thorough sanitization of the source material. According to Socket researcher Karlo Zanki, the repositories became accessible again for a period of approximately seven hours, between 11:09 a.m. and 6:16 p.m. GMT+2. The reason for this temporary restoration of access remains unclear, but the consequences were immediate.

The primary issue lay in the fact that the release tags for the actions were never cleaned. In the world of GitHub Actions, developers typically reference a specific version of a tool using a tag, such as "v1" or "v1.2.3." These tags are mutable, meaning they can be moved to point to different commits in the repository’s history. When the "actions-cool" repositories were re-enabled, these version tags still pointed to the malicious commits introduced by the attackers back in May. Consequently, any automated workflow that was set to run on a schedule or triggered by an event—such as a new pull request—would have automatically downloaded and executed the payload upon its next run.

This "reactivation" of a months-old threat is particularly concerning because it required no new effort from the original attackers. There was no need for a new exploit, no requirement to hijack new accounts, and no necessity to set up fresh infrastructure. The threat was essentially "baked in" to the repository, waiting for the moment it became downloadable once more. Because the housekeeping actions are designed to run frequently—often daily or even hourly—the window of exposure was more than enough time for the malware to execute in thousands of environments.

The incident serves as a stark warning about the dangers of relying on mutable version tags in software development. As Karlo Zanki observed, most supply chain incidents involve a "new" element—a fresh piece of malware, a newly stolen credential, or a sudden change in configuration. In this case, the danger was entirely historical. The fact that a compromised tag can be contained and then reactivated without any change to a user’s own workflow file underscores the fragility of the current trust model in open-source automation.

To mitigate such risks, security experts have long advocated for the practice of "SHA pinning." Instead of referencing a GitHub Action by a version tag like "v2," developers are encouraged to use the full, immutable commit SHA (a long string of characters representing a specific, unchangeable snapshot of the code). While version tags can be moved to point to malicious code, a commit SHA is permanent. If a repository is compromised and a tag is moved, a workflow pinned to a SHA will continue to use the known-good version of the code from before the breach occurred.