Summary
- Malicious @subql/common 5.8.3 was published on 5 October.
- The package steals AWS, GitHub, Kubernetes and Vault credentials.
- Attackers altered CI/CD and published through GitHub Actions OIDC.
Attackers compromised the development pipeline behind the @subql/common npm package and used its legitimate GitHub Actions publishing workflow to distribute malicious code capable of stealing cloud and development credentials.
Researchers at GMO Flatt Security analysed version 5.8.3 after it was published on 5 October and found information-stealing functionality alongside a command-and-control backdoor. A postinstall hook causes the malicious payload to execute when the affected package is installed.
The code searches for credentials associated with AWS, GitHub, Kubernetes and HashiCorp Vault before sending collected information to attacker-controlled infrastructure. It can also accept remote commands through a reverse shell, allowing the compromise to extend beyond the initial theft of secrets.
The publication route distinguishes the incident from package takeovers based solely on a stolen npm password or reusable registry token. Researchers found that the attacker modified the GitHub Actions workflow in the SubQL repository before triggering the project’s existing OpenID Connect trusted publishing process.
Trusted publishing is intended to reduce reliance on persistent package-registry credentials. Instead of storing a reusable npm token in a repository or build system, an authorised CI workflow can obtain a short-lived identity and use it to publish a package.
That removes one valuable secret from the software supply chain but shifts trust towards the repository and workflow authorised to request the publishing identity. Once the attacker could modify the workflow itself, the registry received the malicious release through infrastructure that had already been designated as an approved publisher.
GMO Flatt Security found that the tampered workflow downloaded a malicious package archive from external infrastructure and replaced the legitimate build immediately before publication. Version 5.8.3 was then released through GitHub Actions OIDC at 11:56 UTC on 5 October.
From the package registry’s perspective, the release carried the expected trusted-publisher identity, making authentication metadata alone a poor indicator that the contents had been altered. The attacker did not need to defeat npm’s trust mechanism after gaining sufficient control over the workflow that mechanism was designed to trust.
The incident therefore exposes a boundary between package authentication and build integrity. OIDC can establish which workflow published a release, but it cannot independently establish that code entering the authorised workflow remains legitimate after the repository or automation has been compromised.
The stolen credentials create additional downstream risk because CI systems and developer environments commonly have access to cloud accounts, source repositories, clusters and secrets-management platforms. A malicious dependency can consequently open routes into infrastructure that has no direct vulnerability in the npm package itself.
Removing version 5.8.3 stops that package from executing in future installations, but any credentials accessible while it ran may already have lost their secrecy. Rotation and investigation therefore remain separate from replacing the dependency where an environment installed the malicious version.
The attack does not demonstrate that trusted publishing should be abandoned. Short-lived OIDC identities reduce the risks associated with reusable publishing tokens, but the SubQL compromise shows that repository access, protected workflows and build provenance remain part of the same security boundary.
