Topic starter
02/08/2026 11:48 am
TL;DR: An analysis of the jsonspack campaign shows 27 malicious npm packages using silent loaders, multi-channel C2 delivery, and credential theft routines that target browsers, wallets, and .env secrets, according to Panther. The case underscores how package trust, not just install-time checks, now defines supply-chain risk.
Editorial analysis by NHI Mgmt Group, based on content published by Panther: “jsonspack: Multi-Tenant Node.js RAT â DPRK Supply Chain Campaign”.
By the numbers:
- The jsonspack campaign involved 27 confirmed malicious npm packages published between 2026-03-18 and 2026-03-31.
- Panther recorded 3,739 total downloads across the 27 packages as of 2026-04-01.
Key questions
Q: What breaks when malicious npm packages execute on import instead of install?
A: Install-time controls often miss import-time payloads because the malicious code lives in the published bundle and runs when the module loads.
Q: Why do malicious packages that steal secrets create identity risk beyond the developer workstation?
A: Because secrets are often the keys to downstream systems, not just local tools.
Q: What signs suggest a package supply chain campaign is using shared loader infrastructure?
A: Look for repeated author metadata, similar package naming patterns, common loader structures, and multiple payload channels tied to the same family.
Practitioner guidance
- Restrict runtime execution of untrusted packages Instrument Node.js environments so package imports and child-process launches are visible, then alert on unexpected require()-time behaviour from newly added dependencies.
- Verify package provenance before dependency adoption Review maintainer identity, release history, and namespace consistency for npm packages that resemble legitimate tooling or common plugins.
- Scan developer and build environments for exposed secrets Search for .env files, browser credential stores, wallet extensions, and long-lived API keys that could be harvested if a dependency is compromised.
Bottom line: Malicious npm packages can turn ordinary dependency imports into a runtime secret-theft path, which collapses the assumption that installation review is enough.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 12:58 pm
Package trust has become an identity problem, not only a software supply chain problem. When malicious npm modules can harvest browser credentials, wallets, and .env secrets, the downstream effect is unauthorized access to both human and non-human identities. That means dependency governance now sits inside the access-control conversation, not beside it. Practitioners should treat package provenance as part of identity risk management.
A few things that frame the scale:
- Breaches involving third parties rose to 48% of all breaches, a 60% increase on the previous year, according to Verizon's 2026 Data Breach Investigations Report.
A question worth separating out:
Q: How should security teams respond when a dependency may have accessed secrets at runtime?
A: Contain first by identifying which credentials were exposed, then revoke or rotate the secrets that are still valid. Review pipeline logs, runtime telemetry, and outbound traffic for evidence of reuse. The goal is to cut off legitimate authentication paths that attackers can reuse, not just to remove the malicious package.
👉 Read our full editorial: jsonspack supply chain campaign exposes npm loader and secret theft