Compromised GitHub Actions re

* Two GitHub Actions from actions-cool were disabled for a second time and subsequently re-enabled.
* The compromised repositories were actions-cool/issues-helper and actions-cool/maintain-one-comment.
* Malicious code remained in the repositories after being made accessible again.
* Disabling occurred on May 18, 2026.
* Re-enablement occurred on September 16, 2026.
* The malicious activity was linked to the Mini Shai-Hulud campaign due to npm package overlaps.
* Execution of the payload was possible if workflows referenced the actions by version tag.
* The incident highlights risks associated with mutable tags and the reactivation of code without workflow changes.

The sequence of events reveals a failure not just in initial detection but in the persistent remediation lifecycle of a software supply chain vulnerability. The core pattern observed is the deliberate introduction of an exploit, followed by an inadequate patch (re-enabling the repository) that fails to address the root state—the persistence of malicious code tied to mutable tags. This mirrors systemic vulnerabilities where security fixes are treated as discrete events rather than continuous state management.
The shift from disabling to re-enabling demonstrates a vulnerability in operationalizing security: if code is restored without scanning or scrubbing, the mechanism for harm remains latent within the system's configuration. The fact that workflows referencing version tags could automatically re-trigger the payload upon execution points toward an implicit trust placed in artifact versions rather than immutable state verification. This process effectively leverages development velocity against defensive posture, turning a security incident into an operational risk tied to CI/CD timing.
The implication for agency centers on shifting from reactive response to proactive structural integrity. The reliance on pinning commits and rotating secrets is a direct attempt to re-establish immutable boundaries where automated processes cannot retroactively introduce malicious state. The larger pattern suggests that supply chain risks are amplified when the mechanisms designed to automate development (workflows, tags) become vectors for persistence rather than just delivery. What safeguards must exist outside of repository settings to ensure that security remediation is a permanent operational change, not a temporary administrative action?