Re-Enabled Actions Still Malicious: 5 CI/CD Myths

When GitHub re-enabled two compromised Actions on September 16 without cleaning their malicious payloads, workflows resumed executing Mini Shai-Hulud code for nine days. This incident exposed roughly 15,000 dependent repositories to the same threat GitHub had blocked in May.

These myths persist because CI/CD security often gets treated as a one-time setup rather than an ongoing validation discipline. Teams assume platform-level controls provide complete protection or that disablement equals remediation. Here's what the evidence actually shows.

Myth 1: Platform Disablement Means Permanent Remediation

Reality: Disablement is containment, not cleanup. When GitHub disabled actions-cool/issues-helper and actions-cool/maintain-one-comment in May after detecting Mini Shai-Hulud infections, the malicious commits remained in version history. Re-enabling the repositories on September 16 restored access to those same compromised release tags without verification.

Your monitoring protocol before re-enabling any third-party component must include:

• Commit-level inspection of all tags and branches referenced in your workflows
• Verification that malicious code has been purged from version history, not just HEAD
• Confirmation that maintainers have rotated signing keys or credentials
• Review of the component's dependency tree for transitive infections

Don't assume the platform validates cleanup. GitHub's dependency graph showed 15,000 repositories depending on issues-helper, but the platform re-enabled access without forcing tag cleanup first.

Myth 2: Pinning to Version Tags Protects Against Supply Chain Attacks

Reality: Mutable tags provide no integrity guarantee. The September incident proved that version tags can point to different commits over time. Workflows referencing actions-cool/[email protected] downloaded clean code before May 18, malicious code from May 18 through initial disablement, nothing during the disabled period, then malicious code again from September 16-25.

Effective dependency management for CI/CD requires:

• Pinning to specific commit SHA-256 hashes, not semantic version tags
• Maintaining an internal mirror or cache of verified action versions
• Implementing hash verification in your workflow YAML
• Treating any tag-based reference as a mutable, unverified dependency

The Mini Shai-Hulud attack affected 323 packages and 639 package versions on npm precisely because version-based references allowed attackers to inject malicious code into existing version identifiers.

Myth 3: Daily-Run Workflows Get More Security Scrutiny

Reality: High-frequency workflows often receive less review because they're considered routine. The compromised actions supported issue-housekeeping tasks that run almost daily in many repositories. Teams assume these maintenance workflows don't access sensitive resources, so they skip the security review applied to deployment pipelines.

Your CI/CD security model should recognize that:

• Issue-management actions typically receive GitHub tokens with broad repository permissions
• Housekeeping workflows run on schedules, not just pull requests, expanding the attack window
• Daily execution means faster credential exfiltration if secrets are exposed
• "Low-risk" workflows often have access to the same secret store as deployment jobs

Review your workflow permissions using the principle of least privilege. If an action only needs to label issues, don't grant it contents: write or access to deployment secrets.

Myth 4: Dependency Graphs Provide Sufficient Visibility for Incident Response

Reality: Dependency graphs show what's connected, not what's vulnerable or actively exploited. GitHub's dependency graph identified 15,000 repositories depending on issues-helper, but couldn't answer the critical triage question: which dependents reference the action by mutable tag versus pinned commit?

When a component in your supply chain is compromised, you need:

• An inventory mapping each workflow to specific action versions (tags or commits)
• Execution logs showing which workflows actually ran during the exposure window
• Secret-access logs correlating workflow runs with credential usage
• A decision matrix for rotating secrets based on workflow permissions, not just dependency presence

Socket's researchers noted they couldn't establish how many dependents used mutable tags. Your TPRM program should maintain this mapping proactively, not during incident response.

Myth 5: Disabling a Compromised Action Prevents Further Damage

Reality: Disablement stops new infections but doesn't revoke exfiltrated credentials. Between September 16 and September 25, workflows executed the Mini Shai-Hulud payload targeting developer tokens, credentials, and CI/CD secrets. GitHub disabled the actions again on September 25, causing dependent workflows to fail rather than execute malicious code.

But any secrets accessed by workflows during that nine-day window are now compromised. Your vendor breach management protocol must include:

• Immediate rotation of all secrets accessible to workflows that ran the affected action
• Review of execution logs from the exposure start (September 16, 11:09 GMT+2 in this case) through containment
• Analysis of what the payload targeted, Mini Shai-Hulud specifically hunts tokens and CI/CD secrets
• Monitoring for unauthorized access using potentially exfiltrated credentials

Disablement contains the threat. Secret rotation and access review remediate the exposure.

What to Do Instead

Build a reactivation validation process for any third-party component that was disabled for security reasons:

1. Require maintainer attestation that malicious code has been removed from all branches, tags, and version history
2. Conduct independent verification by reviewing commits and running security scans before re-enabling
3. Pin to verified commit hashes rather than trusting version tags post-incident
4. Rotate credentials as a precaution even if you believe the component wasn't actively used during compromise
5. Monitor for nine days minimum after re-enabling, matching the exposure window in this incident

For your broader CI/CD security: maintain an inventory of every third-party action, pin to commit SHAs, scope workflow permissions narrowly, and treat housekeeping workflows with the same security rigor as deployment pipelines. The 15,000 repositories depending on a simple issue-helper action demonstrate how widely "low-risk" components spread through your supply chain.