Restored GitHub Actions Repositories Briefly Revived a Dormant Supply-Chain Payload

Repository access brought old malicious tags back to life

Two GitHub Actions maintained by actions-cool briefly became accessible again on September 16, 2026, reviving malicious code left behind during the Mini Shai-Hulud campaign.

The affected repositories were:

• actions-cool/issues-helper
• actions-cool/maintain-one-comment

Both had originally been compromised on May 18, 2026. Their release tags were never fully cleaned after that incident and continued to reference attacker-modified content.

When repository access returned, workflows that depended on those mutable version tags could once again download and execute the payload. Users did not need to edit their workflow files, and the attackers did not need to publish another release.

Socket researcher Karlo Zanki said the repositories were available from 11:09 a.m. until 6:16 p.m. GMT+2 on September 16. They were subsequently disabled again.

GitHub’s notice stated that staff had blocked access because of a terms-of-service violation. It is not known why the repositories were re-enabled or what process allowed previously malicious references to become downloadable again.

Mutable tags converted restoration into execution

GitHub Actions workflows can load third-party automation through references such as:

uses: actions-cool/[email protected]

The reference after the @ may identify a version tag rather than an immutable commit. A tag can continue pointing to compromised content—or be redirected to different content—without any corresponding modification in the downstream workflow.

That distinction drove this incident. Once GitHub restored access to the actions-cool repositories, runners could resolve the existing tags and retrieve the malicious code already stored upstream.

The actions-cool/[email protected] reference must be treated as compromised. An exact affected version for actions-cool/maintain-one-comment has not been disclosed, so organizations should investigate every use of that Action rather than assuming a particular tag is safe.

No new code publication, workflow configuration change, exploit or attacker-controlled infrastructure was necessary. Repository availability alone reactivated the distribution path.

Workflows pinned to the complete commit SHA of a known-clean version predating May 18, 2026, were not affected. Unlike a mutable tag, a full commit hash fixes the dependency to a specific repository state.

Routine issue automation created frequent execution opportunities

The compromised Actions perform common repository-maintenance tasks, including checking newly opened issues, closing inactive ones and keeping a single automated comment updated.

Such jobs are often configured to run daily or in response to activity such as a new issue or pull request. That scheduling created multiple opportunities for the restored repositories to reach CI/CD runners during the seven-hour availability window.

Socket assessed that many dependent repositories may have executed the payload within a day of the Actions becoming available. No further interaction from the threat actor would have been required.

The malicious code attempted to harvest credentials available inside the CI/CD environment and transmit them to an attacker-controlled server. The known exfiltration indicator is:

t.m-kosche[.]com

Any repository that ran either Action during the relevant period should therefore be investigated for possible secret exposure. The potential impact extends beyond the individual workflow because stolen credentials may provide access to repositories, build systems or software-publishing processes.

The specific credentials collected from each affected environment are not known. Exposure depends on which secrets and permissions were available to the job when the compromised Action executed.

Evidence connects the activity to Mini Shai-Hulud

The incident is associated with the Mini Shai-Hulud activity cluster, which also involved npm packages from the @antv ecosystem.

Socket head of threat intelligence Philipp Burckhardt assessed that the shared exfiltration domain connected the GitHub Actions compromise and the npm activity to the same cluster. In that assessment, the overlap did not support treating the npm component as a separate incident.

The important mechanism here was persistence in the software supply chain. The attacker’s content remained behind references that downstream repositories already trusted. Disabling the upstream repositories interrupted delivery, but it did not remove the compromised objects.

Consequently, restoring availability also restored the attack path. Existing workflow configurations became dangerous again despite remaining unchanged.

Repository owners should rotate secrets and inspect execution history

Defenders should first search all workflow files for references to both affected Actions. This includes current files, reusable workflows and older branches that may still trigger automation.

At minimum, response teams should:

1. Treat actions-cool/[email protected] as compromised.
2. Remove both actions-cool dependencies or replace them with a verified, full commit SHA predating May 18, 2026.
3. Rotate every secret that may have been available to affected workflow jobs.
4. Review workflow-run history for successful executions after a prolonged sequence of Set up job failures.
5. Investigate runs associated with the September 16, 2026 availability window.
6. Audit repository history for unexpected commits made after September 16, 2026.
7. Search network, proxy and CI/CD telemetry for connections to t.m-kosche[.]com.

Secret rotation should not be limited to credentials already confirmed as stolen. If a token, key or password was accessible to a job that successfully loaded the malicious Action, defenders should assume exposure unless execution evidence proves otherwise.

Repository owners should also review the permissions assigned to affected workflow tokens. The consequences of credential theft depend heavily on whether those tokens could only read source code or could modify repositories and related release processes.

Commit pinning limits the risk from revived dependencies

This episode illustrates a specific weakness in tag-based GitHub Actions dependencies: trust remains tied to the changing state of an external repository.

A workflow referencing @v2.2.1 may look fixed, but the tag is not equivalent to an immutable software artifact. Its security can change when the upstream repository is modified, compromised, removed or restored.

Pinning third-party Actions to full commit SHAs narrows that risk because the workflow requests one exact revision. Organizations still need to verify the selected commit and monitor upstream security events, but repository restoration cannot silently redirect the pinned reference to different code.

Access controls and takedowns remain useful containment measures. They are not remediation for malicious content that still exists behind trusted release tags.