Check Your GitHub Workflows for Two Compromised Actions
Matthew Leo · Published September 28, 2026 · Guides
Two GitHub Actions that had been disabled after a malware campaign became downloadable again on September 16, 2026, while their release tags still pointed to compromised code. The actions, actions-cool/issues-helper and actions-cool/maintain-one-comment, were disabled again by September 25. A broken workflow today does not prove it was safe during the days they were available.
If you maintain repositories that automate issue or comment housekeeping, check whether either action appears in your workflow files. Security company Socket documented the re-enablement and a sample of affected runs; BleepingComputer reported the renewed exposure. Socket does not know how many repositories actually ran the malicious code, so the number of projects that depend on an action should not be read as a victim count.
Find the action references
In each repository, open the .github/workflows/ folder. Search the workflow files for actions-cool/issues-helper@ and actions-cool/maintain-one-comment@. Include branches that ran during the exposure window, not just the default branch today. An organization with many repositories should search its code inventory rather than checking projects one by one.
Record the reference after the @ symbol. A version such as @v2.2.1 is a tag that can resolve to different code over time. Socket says the affected release tags still pointed to the malicious payload when the repositories were re-enabled. A full commit SHA fixes the code to one revision, but only if that exact revision has been checked and is clean. Do not replace an affected tag with an arbitrary SHA found in a discussion thread.
If you find either action, remove or disable that workflow step while you investigate. Issue labels and stale-comment automation can wait. Security work becomes harder if another scheduled run starts during the check.
Review runs from September 16 onward
Open the repository's Actions tab and inspect runs of workflows that referenced the action from September 16 until it was disabled again. GitHub's run-history guide explains where to find a workflow's previous runs. Check the job setup and step logs. Socket observed runs that had previously failed because the repository was blocked, then began succeeding and took several minutes after the actions became available again.
Socket also saw oven-sh/setup-bun downloaded and a Bun command running the action's JavaScript file in a sample job. Those details can help triage logs, but their absence is not proof that a workflow was safe. GitHub logs can be incomplete or unavailable, and a run that says “success” can still have executed unwanted code before finishing its normal task.
Check for unexpected commits, release changes and newly created credentials after any suspect run. If the workflow had write permission, look at what its GITHUB_TOKEN could do at the time. Review each secret made available to the job, including organization secrets and deployment credentials. A compromised action may access material available in its job even if the workflow's intended purpose was minor.
Rotate what the job could reach
For a run that used an affected tag during the exposure window, treat accessible secrets as exposed. Replace the values at the services that issued them, then update the repository or organization secrets. Revoking the old credential matters; only changing the value stored in GitHub leaves the old credential usable elsewhere. If the job could publish packages, deploy a site or access cloud infrastructure, check those services' audit logs too.
GitHub's secure-use guidance recommends limiting GITHUB_TOKEN permissions, protecting secrets and pinning third-party actions to full commit SHAs. Apply those controls after the incident check. A pin reduces the risk of a tag moving later; it does not make a malicious commit safe.
When you can turn a workflow back on
Keep the affected step off until you can replace it with a reviewed clean action or implement the small task another way. Review the new action's permissions and the event that triggers it. Issue and comment events may be triggered by people outside your organization, while scheduled workflows run without anyone watching each execution.
If you discover suspicious activity, preserve the run IDs, logs and relevant commit history before deleting anything. Escalate through your organization's incident process and report the affected action to GitHub. The key question is whether a workflow actually ran with the compromised reference and what access it had, not whether the repository appears healthy now.