Deceptive Tags and Impostor Commits: the new attack vector in the software supply chain

In a new example of how the software supply chain remains an attractive vector for the attackers, the verification of GitHub's popular action has been detected. actions-cool / issues-helper, where malicious actors moved all the tags in the repository to point them to a commit impostor which is not part of the legitimate project history. The result: any workflow that refers the action by label or by version instead of by a reliable commit SHA could download and run malicious code in the GitHub Actions runner in the next run.

The impostor commission technique exploits a less well-known property of the tags: unlike an irrevocable SHA, a label can be reassigned by anyone who controls the repository or a malicious fork. In this case, the injected code downloads the runtime Bun, tries to read the Runner.Worker process memory to extract credentials present in the CI / CD environment and sends the data to a server controlled by the attacker ("t.m-kosche [.] com"). According to the first analysis, the same tactic affected another related repository, actions-cool / maintain-one-comment, and the exfiltration infrastructure connects this incident with a previous wave that attacked npm packages in the @ antv ecosystem, suggesting a possible coordinated operation on multiple fronts.

The implications for open source organizations and projects are clear and profound: it has been shown that CI / CD integrations can become a direct vector for the extraction of secrets. GitHub Tokens, cloud credentials, API keys and other secrets that are used in automated workflows can be read and exfiltered if an actor manages to run arbitrary code on the run. In addition, the ease to spread the commitment - change tags that many actions use by default - magnifies the scope of the potential damage.

The defence against such attacks should combine immediate technical changes and broader software governance policies. As soon as possible, review all workflows using third-party shares and replace any non-solid reference (e.g. use "v1" or a label) with a known and audited commitment SHA. GitHub offers recommendations and guides to hardening GitHub Actions that explain good practices such as pinning to SHAs, limiting workflow permits and protecting secrets; these guidelines are available in the official documentation of Actions: https: / / docs.github.com / en / actions / security-guides / security-hardening-for-github-actions.

Rotation of credentials and containment are indispensable steps once possible exposure is detected. If a potentially vulnerable repository or workflow has run since the impostor commission was published, take commitment and rotate tokens and keys used by those workflows is the prudent measure. In parallel, exit traffic to suspicious domains should be blocked in DNS resolution and in internal network firewalls to prevent data from continuing to come out while it is being investigated.

On a strategic level, this incident reinforces the need to adopt more robust supply chain integrity practices, such as the SLSA (Supply-chain levels for Software artifacts) model, which proposes controls to ensure the provenance and immutability of the artifacts: https: / / slsa.dev /. In addition, implement federated authentication without embedded secrets (e.g. OIDC for cloud suppliers), execution runners with less privileges and time, and strict review and approval policies for the inclusion of third party actions, reduces the exposure area.

For teams that manage open source projects or CI infrastructure in companies, it is also appropriate to audit the use of tags and forks that have access to publish versions, and to encourage pipelines that do not expose secrets to third-party actions. Supply chain and reputation scanning tools for packages and actions, as well as abnormal behavior monitors in runners - for example, unusual downloads of binaries such as Bun or outbound traffic peaks to new domains - help detect early detections.

Finally, the operational lesson is that the security of the supply chain requires both technical controls and an organizational culture that deals with the secrets and dependencies of third parties and elements of critical risk. If your organization runs affected workflows, act already: identify references to actions-cool and other third party actions, replace labels with verified SHAs, revoke and renew exposed credentials and tighten the permissions of your pipelines. Prevention and rapid response are the difference between a manageable interruption and a high impact filtration.