Two GitHub Actions hijacked in May's Mini Shai-Hulud supply-chain campaign were made available again this month with their malicious code still in place, BleepingComputer reported Saturday, citing application security firm Socket. Both actions were disabled again on Sept. 25.

What Happened

The affected actions are actions-cool/issues-helper and actions-cool/maintain-one-comment. Both were compromised on May 18, 2026, during the Mini Shai-Hulud attack. After the compromise was discovered that day, GitHub's security team removed the actions, which stopped workflows from downloading them.

According to Socket, both repositories became accessible again on Sept. 16, sometime between 11:09 and 18:16 GMT+2. Their release tags had not been cleaned up first and still pointed to the content introduced on May 18. The malicious code sits in obfuscated index.js files and is designed to collect developers' tokens, credentials and CI/CD secrets.

RelatedNew curl Release Fixes 24 Flaws, Including a High-Severity Bug Reported With Anthropic’s Claude

GitHub's dependency graph lists about 15,000 repositories that depend on issues-helper, although not all of them necessarily pulled the tainted version during the window. The actions were disabled again on Sept. 25, so workflows that reference them now fail instead of running the payload. BleepingComputer said it is unclear why the repositories were restored without the tags being fixed, and the report carried no explanation from GitHub or the maintainers.

The original May campaign compromised 323 npm packages across 639 versions.

Why It Matters

Most workflows reference third-party actions by a version tag such as v2 or v3. A tag is a movable pointer: whatever commit it points to at run time is the code that executes, with whatever permissions and secrets the workflow has been given. That is why restoring a repository with its old tags intact effectively redistributed the May payload to anyone who had not removed or pinned the action.

CI runners are an attractive target because they often hold npm publish tokens, cloud credentials and repository write access. Shai-Hulud-style worms use exactly those secrets to publish poisoned versions of other packages, which is how a single compromise spreads across a registry. A token stolen from a build job on Sept. 16 could still be valid today if it has not been rotated.

The case also exposes a gap in how compromised projects are brought back. Taking a malicious action offline limits damage, but returning it to service without checking that every tag resolves to clean code undoes that protection.

What Teams Should Do

Socket's guidance is to search all workflows for references to the two actions, then either remove them or pin them to a verified clean commit. Teams should review any workflow runs that used them since Sept. 16 and rotate every secret those workflows could access, including tokens for package registries and cloud accounts.

More broadly, GitHub's own security hardening guidance recommends pinning third-party actions to a full-length commit SHA rather than a tag, because a commit hash cannot be moved to point at different code.

What to Watch

Watch for a statement from GitHub on how the two repositories were restored, and whether it adds checks on tags and releases before re-enabling a previously compromised project. Also watch for signs of follow-on package compromises traced back to secrets exposed during the September window.