Kalyxo
Malicious SubQuery package release targets developer credentials
Published
A compromised @subql/common release added install-time and import-time malware. Here is what the evidence shows and what affected teams should check.
On October 5, version 5.8.3 of the SubQuery JavaScript package @subql/common was published with code absent from 5.8.2. GitHub's malware advisory identifies 5.8.3 as affected and lists no patched version. A public SubQuery repository issue and StepSecurity's package analysis describe a new postinstall hook and an import-time loader in dist/project/readers/manifest-cache.js.
The analysis reports that the payload gathered environment variables, GitHub authentication output, SSH material, npm configuration, cloud and orchestration credentials, wallet files, and AI-agent configuration. It encrypted collected data for transfer to ci-artifacts.dev, installed a command channel, and used stolen GitHub tokens to create a branch containing a workflow designed to expose repository secrets as an artifact. The available reporting does not establish that a victim repository executed that workflow, or document confirmed victim counts. The payload's capabilities should not be presented as proof that every exposed secret was stolen.
The timing also needs care. The issue reports a separate 5.8.3-onf-rt1 release tagged redteam that investigators found did not contain the payload. That earlier release is distinct from the malicious 5.8.3 package. The release path and responsible actor remain unresolved in the sources reviewed here.
Check installations and credentials
As of October 6, the npm registry lists 5.8.2 as the latest version and no longer lists 5.8.3, although cached tarballs, lockfiles, private mirrors, or existing installations can preserve it. Teams should search lockfiles, build logs, caches, and developer or CI environments for @subql/common@5.8.3. Anyone who installed or ran that version should isolate the affected environment, treat credentials accessible to it as exposed, rotate them from a clean device, and review GitHub branches, workflows, and artifacts for unexpected activity. GitHub's advisory recommends treating systems with the package installed or running as compromised.
Package-level controls can reduce the impact of the next compromised release: pin reviewed versions, inspect lifecycle scripts and new transitive code before promotion, restrict CI credentials to the job's actual needs, and monitor for unexpected outbound connections and workflow changes. These steps help contain a malicious package without assuming that a registry's current version tag describes every copy already in use.