What Happened
Attackers compromised the GitHub Actions workflow actions-cool/issues-helper by redirecting every existing tag in the repository to point to malicious commits. These imposter commits contained code designed to exfiltrate CI/CD credentials to an attacker-controlled server at t.m-kosche[.]com. The attack extended beyond a single repository — 15 tags in a second GitHub action were also compromised. StepSecurity identified the attack and linked the exfiltration domain to the Mini Shai-Hulud campaign, suggesting coordinated supply chain targeting.
Your team likely uses GitHub Actions workflows that reference third-party actions by tag (e.g., @v1 or @latest). If you're running actions-cool/issues-helper or similar compromised actions, your pipelines may have already executed the malicious code and sent credentials to the attackers.
Timeline
The attack pattern follows this sequence:
- Initial compromise: Attackers gained control of the repository or maintainer account.
- Tag manipulation: All existing tags were redirected to point to new, malicious commits.
- Execution: Workflows referencing these tags automatically pulled and executed the compromised code.
- Exfiltration: Credentials were sent to
t.m-kosche[.]com. - Detection: StepSecurity identified the unusual domain activity and tag manipulation.
The attack exploited a fundamental trust assumption: that Git tags are immutable references. They're not. Tags can be force-pushed to point to different commits, and most CI/CD systems don't verify tag integrity.
Which Controls Failed or Were Missing
Version pinning to mutable references: Workflows referenced actions using tags like @v1.3.0 instead of full commit SHAs. Tags are human-readable but mutable — an attacker who controls the repository can repoint them at will.
Supply chain verification: No cryptographic verification of action integrity occurred before execution. The pipeline trusted that @v1.3.0 still pointed to the same commit it did yesterday.
Network egress monitoring: The exfiltration to t.m-kosche[.]com should have triggered alerts. Either egress filtering wasn't configured, or the domain wasn't flagged as anomalous for a CI/CD runner.
Least privilege for CI/CD credentials: The stolen credentials likely had broader permissions than necessary. If the workflow only needs to create issues, it shouldn't have secrets that grant repository write access or deployment capabilities.
Repository integrity monitoring: No alerting existed for tag manipulation events. GitHub provides webhook events for tag pushes — monitoring these for force-push patterns would have caught the attack.
What the Relevant Standards Require
NIST 800-53 Rev 5 SA-10 (Developer Configuration Management) requires organizations to "protect the integrity of the information system and information system components by employing configuration management processes." Allowing mutable references in production workflows violates this control. You must pin to immutable identifiers.
ISO/IEC 27001:2022 Annex A.8.31 (Separation of Development, Test, and Production Environments) mandates logical or physical separation to reduce unauthorized access risks. Your CI/CD environment is part of your production infrastructure — it deploys to production, holds production credentials, and must be treated with production-level controls. Using unverified third-party code in this environment creates a direct path from external repositories to your production systems.
OWASP ASVS v4.0.3 Requirement 14.2.1 states: "All components, libraries, and frameworks should come from trusted sources over secure channels." A GitHub tag isn't a secure channel — it's a mutable pointer. The secure approach is to verify the commit SHA and pin to it.
PCI DSS v4.0.1 Requirement 6.3.2 requires that custom software is developed securely, including "security of coding practices for common software attacks." Supply chain attacks that inject malicious code into your build process fall squarely into this requirement's scope. If your CI/CD pipeline processes cardholder data or deploys applications that do, you must secure the pipeline itself.
Lessons and Action Items for Your Team
Audit your GitHub Actions workflows immediately. Run this command in every repository:
grep -r "uses:" .github/workflows/ | grep -v "@[0-9a-f]\{40\}"
Any line that doesn't end with a 40-character hex string is using a mutable reference. You're vulnerable.
Pin all third-party actions to full commit SHAs. Change actions-cool/[email protected] to actions-cool/issues-helper@a1b2c3d4e5f6... (the full 40-character SHA). Yes, this makes updates harder. That's the point — you want intentional, reviewed updates, not automatic execution of compromised code.
Implement Dependabot or Renovate for action updates. These tools will open pull requests when new commits are available for your pinned actions. You review the diff, verify the commit, and merge. This gives you immutability with a manageable update process.
Monitor GitHub webhook events for tag manipulation. Set up alerts for push events where ref matches refs/tags/* and forced is true. A legitimate maintainer rarely force-pushes tags. When it happens, investigate immediately.
Restrict network egress from CI/CD runners. Your build agents should only communicate with known-good domains: your artifact repository, your cloud provider, your container registry. Use network policies or security groups to block everything else by default. The exfiltration to t.m-kosche[.]com would have failed if egress was properly restricted.
Apply least privilege to CI/CD secrets. If a workflow only needs read access to issues, don't give it a token with repository write permissions. Use GitHub's fine-grained personal access tokens or App installations with minimal scopes. When credentials are stolen, you want the blast radius to be as small as possible.
Consider using StepSecurity's Harden-Runner or similar tools. These can monitor outbound network calls from your workflows and alert on unexpected destinations. They won't prevent the compromise, but they'll detect the exfiltration.
Don't assume open-source actions are safe. Popular repositories get compromised. Maintainer accounts get phished. Even actions with thousands of stars can become attack vectors. Treat third-party actions like you treat third-party libraries — with verification and version control.
The actions-cool/issues-helper attack succeeded because teams treated Git tags as immutable and third-party actions as trustworthy. Neither assumption holds. Your CI/CD pipeline is production infrastructure. Secure it accordingly.
