jsonspack supply chain campaign exposes npm loader and secret theft

At a glance

What this is: This is a supply chain attack analysis showing how 27 malicious npm packages used silent loaders and staged payload delivery to steal credentials and secrets.

Why it matters: It matters because dependency trust, runtime execution, and secret exposure now intersect for software teams that must govern both build-time and in-process package behaviour.

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.

Context

Jsonspack is a supply chain campaign in which seemingly ordinary npm packages were used as a delivery mechanism for malicious loader behaviour and credential theft. The security gap is not just malware in a package registry, but the assumption that dependency installation is the main moment of risk. In practice, runtime import behaviour can be enough to trigger harmful code.

For IAM and NHI practitioners, the important lesson is that package ecosystems now intersect with secrets governance, service tokens, browser credentials, and other non-human access paths. When malicious code can harvest secrets from development and execution environments, identity controls cannot stop at the perimeter of the repository or package manager.

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. That means unit tests, bundlers, dev servers, and CI jobs can all trigger execution before a postinstall safeguard ever matters. Teams need artifact validation and runtime detection, not only script blocking.

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. A browser credential, API token, or .env secret can expose cloud services, CI systems, or machine accounts after the initial host compromise. Identity teams should treat leaked secrets as access lifecycle failures with cross-environment impact.

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. Those signals often indicate a campaign platform rather than a single sample. Correlating package behaviour with network destinations and import-time execution is more effective than chasing one hash.

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.

Technical breakdown

Silent require()-triggered loaders bypass install-time checks

The campaign’s core mechanism is not a postinstall hook but code that runs when a package is required in application code. That matters because many defenders focus on install-time scanning and assume a clean install means low risk. Here, the package exports a harmless-looking function that immediately spawns a detached child process, suppresses standard output, and keeps running after the parent exits. This shifts malicious execution into normal runtime behaviour, where dependency resolution and application startup become the trigger point.

Practical implication: runtime monitoring must cover dependency execution, not just package installation.

Multi-channel payload delivery fragments detection

The loaders retrieve stage-2 payloads from multiple delivery channels, which means each package instance can behave slightly differently even when it shares the same basic architecture. That design weakens signature-based detection because defenders cannot rely on one hash, one URL, or one binary to represent the campaign. In effect, the package family behaves more like a delivery platform than a single malware sample, with operator-specific payloads layered on shared loader logic.

Practical implication: detection content should correlate package metadata, network destinations, and runtime behaviour rather than depend on one indicator.

Secret theft extends beyond application credentials

The decoded payload shows a browser credential stealer, crypto wallet collection, file exfiltration focused on .env secrets, and a reverse shell. That combination is important because it spans both developer and end-user trust stores, plus secrets that often underpin downstream non-human identities such as API keys and service credentials. The threat is therefore not limited to one application stack; it can surface in the developer workstation, the CI process, and the runtime environment that consumes secrets.

Practical implication: protect secrets as an environment-wide asset and assume compromised development tools can expose production access paths.

Threat narrative

Attacker objective: The attacker aims to steal credentials and secrets at scale while maintaining flexible access to victim environments through staged payload execution.

1. Entry occurs when a developer or build process imports one of the malicious npm packages, triggering the loader during normal require() execution.
2. Credential harvesting and payload retrieval happen through obfuscated stage-2 delivery channels that load operator-specific code after the initial import.
3. Escalation follows when the payload collects browser credentials, wallet extensions, and .env secrets, then establishes a reverse shell for interactive control.
4. Impact is theft of credentials and secrets that can be reused to access downstream systems, developer accounts, and production-linked non-human identities.

Breaches seen in the wild

• Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.
• reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Runtime trigger design is the named control gap here: import-time execution defeats install-time confidence. The campaign works because the malicious code activates on require(), not during installation, so a clean install provides little assurance. This is the sort of failure mode that conventional package review misses when it only checks hooks and manifests. Teams should move scrutiny to runtime execution boundaries and dependency behaviour.

Multi-channel payload delivery creates supply chain noise that weakens simple blocking strategies. Shared loader logic with different stage-2 channels means defenders face a campaign pattern, not a single artifact. That makes provenance, execution context, and network correlation more valuable than isolated indicators. Security teams should assume the package registry is now an execution surface with branching operator infrastructure.

Secret theft from developer environments is an NHI governance failure because stolen secrets often unlock service access downstream. Once .env files and browser-stored credentials are exposed, the attacker can pivot from human endpoints into machine identities, APIs, and cloud services. That is exactly where IAM and NHI governance intersect: a leaked credential is not just a host compromise, it is an access lifecycle failure. Practitioners should govern secret exposure as identity exposure.

Supply chain abuse is becoming multi-tenant in the attacker sense, which complicates attribution and containment. The article’s evidence suggests shared infrastructure with operator-specific payloads, meaning defenders may be seeing one delivery layer used for many campaigns. That pushes identity and supply chain teams toward stronger segmentation of trust, tighter allowlisting, and better telemetry on package execution. Practitioners should plan for reused infrastructure, not one-off malware.

From our research library:

• 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.
• Read next: AI Supply Chain Security and AI-BOM Guide

What this signals

Package provenance is now part of identity governance. A dependency can become the first hop in a credential compromise chain, which means software supply chain controls and IAM controls are converging in the same incident flow. Teams should watch for the point where package execution becomes secret exposure, then treat that boundary as a policy control surface.

Secret exposure inside developer tooling is a predictable path to non-human identity abuse. Once attackers reach API keys, tokens, and configuration secrets, the problem shifts from malware to access reuse. That is why 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.

Runtime telemetry will matter more than manifest review. Campaigns that activate on import or spawn silent child processes are designed to bypass static package checks. Security programmes should assume that dependency risk is a runtime governance issue, not a one-time source-code review problem.

For practitioners

• 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.
• Correlate package metadata with network telemetry Build detections that join package name patterns, author email reuse, C2 destinations, and unusual outbound connections from development hosts.
• Limit the blast radius of stolen credentials Reduce standing privilege on service accounts and rotate credentials that may have been accessible to development tools or browser-based sessions.

Key takeaways

• Malicious npm packages can turn ordinary dependency imports into a runtime secret-theft path, which collapses the assumption that installation review is enough.
• The article shows that the campaign combined silent loaders, multiple payload channels, and credential harvesting to target browser data, wallets, and .env secrets at scale.
• Teams need to govern dependency provenance, monitor package execution, and rotate any secrets that may have been reachable from developer or build environments.

Key terms

• Runtime Dependency Execution: The moment a package is loaded and code runs inside an application or build process. For identity security, this is where a dependency stops being passive supply chain material and becomes an active execution path that can access local secrets, sessions, and trusted network reach.
• Secrets Exfiltration: The theft of credentials, tokens, API keys, or certificates from a system and their movement to an attacker-controlled location. In developer and automation environments, exfiltration is often hidden inside normal workflow activity, which makes detection and containment harder.
• Package provenance: Package provenance is the ability to prove where software came from, who published it, and whether it has been modified before installation. In MCP sprawl, weak provenance means installation can happen faster than trust can be established, which increases secret exposure risk.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course, the industry's only accredited NHI security programme. It is designed for practitioners who need to connect access governance, secrets management, and machine identity risk.