Compromised GitHub Actions Reappear With Mini Shai-Hulud Payload Still Live

BleepingComputer reports that two third-party GitHub Actions previously compromised as part of the "Mini Shai-Hulud" campaign were re-enabled by their maintainer and remained publicly accessible for more than a week — while still pointing to malicious code.

Why it matters

GitHub Actions are widely reused as build/CI dependencies, often pinned by tag or branch rather than a fixed commit hash. When a compromised Action is "restored" without a full compromise assessment, any pipeline that references it — directly or transitively — can silently pull malicious code back in, even if the org previously remediated the original incident. This is a supply-chain risk for any team consuming third-party Actions in CI/CD, not just direct victims of the original campaign.

What defenders should watch for

• Inventory CI/CD workflows for any reference to the affected Actions (by repository/marketplace name) and check whether they are pinned to a mutable ref (branch/tag) versus a fixed commit SHA.
• Review recent CI run logs for unexpected network egress, unfamiliar processes, or secrets/environment variable access during workflow execution.
• Treat "re-enabled" or "restored" third-party Actions with suspicion until the maintainer publishes a verified clean commit hash — re-enablement alone is not evidence of remediation.
• Consider requiring commit-SHA pinning (not tag/branch pinning) for all third-party Actions as a standing control, and monitor for changes to pinned SHAs in dependency-review or CODEOWNERS-gated PRs.

This is developing, net-new intelligence with details still emerging; no CVE or formal advisory is associated with it at this time. For the original reporting, see BleepingComputer's coverage.