A pair of third-party GitHub Actions that had been targeted in the Mini Shai-Hulud supply-chain attack were restored to working status by their maintainer, yet remained dangerous because they still directed to malicious code. The GitHub security team had disabled actions-cool/issues-helper and actions-cool/maintain-one-comment on May 18 following the initial compromise, blocking workflows from retrieving the infected material.
Between September 16 and September 25, both actions became operational once more under their original release tags, according to findings from Socket, an application security research firm. This meant that any workflow configured to use these actions by version tag would pull down and run the old malicious payload again.
The May incident, known as Mini Shai-Hulud, had compromised 323 packages and 639 package versions across the Node Package Manager (npm) registry. The malware was designed to steal developer tokens, credentials, and CI/CD secrets from affected systems.
Socket's researchers discovered that when the release tags for both actions resolved again on September 16, they pointed to commits containing obfuscated malicious code in the index.js file. "On September 16, 2026, both repositories became accessible again. Their release tags were not cleaned up first," Socket stated. "They still point to the malicious content introduced on May 18, so any workflow that references either action by a version tag resumed downloading and executing the payload on its next run."
The reason for re-enabling these repositories without first removing the malicious content remains unclear. GitHub's dependency tracking shows approximately 15,000 repositories depend on the issues-helper action alone, though not all of these necessarily experienced compromise. Socket has not yet determined how many of these dependents reference either action using mutable tags rather than pinned commits.
The affected actions typically run on a near-daily schedule because they handle issue maintenance tasks. On September 25, GitHub disabled both actions again, which caused workflows referencing them to fail rather than execute the payload.
The window of exposure lasted from September 16 between 11:09 and 18:16 GMT+2. Socket recommends that potentially affected developers locate any references to these actions, either remove them entirely or pin them to a verified clean commit, audit workflow runs that occurred since September 16, and refresh any secrets that workflows had access to during the compromise period.