SubQuery backdoored npm dependency
Report edition: 22 October 2026 · PDF page 16
Research reviewed 22 October 2026 · Evidence and editorial planning guidance are distinguished below.
- Operational priority
- Critical
- Evidence
- Independent technical analysis
Malicious common package published 5 October 2026
Priority is conditional on actual exposure. An asterisk highlights especially conditional exposure; these are editorial judgments, not CVSS scores.
Explore this topic in depth
Ten detailed reports: four shared analyses and six audience perspectives. Research reviewed 22 October 2026; the original PDF account remains below as a dated snapshot.
Research update and qualifications
StepSecurity’s investigation describes a malicious @subql/common package and credential-access behavior in the release path. It examines distributed artifacts and their provenance rather than relying only on repository source. The relevant exposure is package installation or execution in a particular environment.
StepSecurity SubQL ecosystem investigation · Original package investigation revisited.
A registry download count is not a count of compromised organizations. A valid artifact hash proves identity against that reference, not that the referenced contents are safe.
The original PDF snapshot
What the report establishes
Researchers found credential theft and remote-command capability in @subql/common 5.8.3. The malicious release used a modified publishing workflow and could start on installation or import.
Impact and potential reach
Direct and transitive consumers resolving the affected package, especially developer workstations and CI runners. Package reach is not a count of compromised users.
Required actions
Engineering owners: block 5.8.3, inspect lockfiles and executed builds, isolate affected runners and rotate reachable secrets from clean systems. Use a verified unaffected version. Disabling install scripts alone does not prevent the import trigger.
Six perspectives on this topic
For the business manager
Coordinate delivery around the affected build and release paths. Not every product requires the same action, and a development incident does not automatically establish customer compromise. Ask engineering to provide a scoped release-readiness decision that operations can use.
Read the business manager report for priorities, evidence and a decision checkpoint.
For the business owner
Assess the business authority attached to build environments. A low-cost dependency can sit beside credentials capable of publishing trusted software. Fund investigation of the release path and decide what independent assurance is proportionate to the products at risk.
Read the business owner report for priorities, evidence and a decision checkpoint.
For the technical manager
Investigate transitive dependencies and artifact behavior, not only direct package declarations. Coordinate endpoint, CI and identity evidence to determine exposure. Keep product integrity conclusions separate from whether an affected package appeared in a build.
Read the technical manager report for priorities, evidence and a decision checkpoint.
For the software engineer
Trace the actual resolved package and lifecycle behavior in the build environment. Compare verified artifacts and intended source through the response process; do not execute suspect code just to inspect it. Use a clean rebuild to establish the replacement output.
Read the software engineer report for priorities, evidence and a decision checkpoint.
For the customer service
Give customers product-specific release information rather than unqualified package-ecosystem warnings. Record the version and distribution channel when escalating a concern. Avoid asking customers to run diagnostic commands copied from a security thread.
Read the customer service report for priorities, evidence and a decision checkpoint.
For the customer
Follow the software supplier’s official product notice if one is issued. A development-package incident requires investigation, but does not prove that every product using the ecosystem was malicious. Keep version information available and avoid unofficial replacement downloads.
Read the customer report for priorities, evidence and a decision checkpoint.
In this section
- SubQuery: Evidence and scopeA registry download count is not a count of compromised organizations. A valid artifact hash proves identity against that reference, not that the referenced contents are safe.
- SubQuery: Business impact and costsA dependency introduced for one feature may reach authority used to publish unrelated software. The business needs to distinguish affected development environments from released products and investigate whether the release process itself was used.
- SubQuery: Technical exposure and controlsUse lockfiles and build evidence to identify exact artifacts and transitive paths. Establish where installation or execution occurred and which repository, publishing, cloud or service credentials were available there.
- SubQuery: Response and recoveryAuthorize releases only when the build environment, publishing identity and resulting artifacts have sufficient evidence of integrity.
- SubQuery: Business manager reportWhich customer commitment depends on a pipeline whose integrity is still unresolved?
- SubQuery: Business owner reportWhat evidence would let us confidently distribute a new version after this incident?
- SubQuery: Technical manager reportWhere could the same dependency run outside the application repository we first checked?
- SubQuery: Software engineer reportDoes our verification test the package contents or only the label attached to them?
- SubQuery: Customer service reportCan we identify the product version this customer actually obtained?
- SubQuery: Customer reportIs this advice tied to my installed product or to a general package warning?