jsonspack supply chain campaign exposes npm loader and secret theft

At a glance

What this is: This is a Panther analysis of a malicious npm supply chain campaign that used package impersonation, silent execution on require(), and staged payload delivery to steal credentials and exfiltrate secrets.

Why it matters: It matters because software supply chains increasingly carry non-human identity risk through packages, tokens, and developer tooling, so IAM, PAM, and AppSec teams need controls that cover runtime behaviour, not only package installation.

By the numbers:

• 27 confirmed malicious npm packages were published by eight distinct email accounts between 2026-03-18 and 2026-03-31.
• 3,739 total downloads were recorded across all 27 packages as of 2026-04-01.
• 15 were unpublished and no longer publicly accessible, but were recovered from an npm package mirror.

👉 Read Panther's analysis of the jsonspack npm supply chain campaign

Context

The jsonspack campaign is a supply chain compromise, not a simple malicious package upload story. The important security problem is that the packages are designed to execute only when required at runtime, which means install-time scanning can miss the actual malicious behaviour. For teams managing software supply chains, this is also an NHI problem because package tokens, CI credentials, and developer trust boundaries are all part of the attack surface.

Panther’s analysis shows a pattern that security teams should treat as increasingly normal in npm ecosystems: plausible package naming, hidden loader behaviour, and staged command-and-control delivery. The first lesson is that package metadata alone is not a reliable trust signal. The second is that secrets exposure in build and runtime environments can become the real payload, even when no obvious malware is present at installation time.

Key questions

Q: What breaks when malicious npm packages execute during CI/CD installs?

A: The main failure is that package installation becomes code execution inside a trusted build context. That lets attacker-controlled scripts read memory, steal secrets, and potentially publish more malicious artifacts before defenders notice. The control that breaks is the assumption that dependency installation is operationally harmless. Treat install-time execution as a governed security boundary, not a routine developer convenience.

Q: Why do malicious packages create NHI risk as well as AppSec risk?

A: Because the package often lands inside an environment that already holds credentials, API keys, and automation tokens. Once execution starts, the package can steal secrets that function as non-human identities in practice. The result is not only code compromise but identity compromise, since the attacker can reuse those secrets to move into cloud, source control, or pipeline systems.

Q: What do security teams get wrong about package provenance and trusted publishing?

A: They often assume provenance replaces older authentication paths automatically. It does not. If a legacy token, secret, or key remains valid, the attacker can use that path even when provenance controls exist. The control failure is leaving old and new trust models active at the same time.

Q: How should organisations respond when a developer package is confirmed malicious?

A: Contain the affected hosts, identify every system that imported the package, and revoke any credentials that may have been accessible in those environments. Then review browser profiles, CI runners, and local files for secondary theft. The immediate goal is to remove the attacker’s reuse path before they pivot from the package to wider identity abuse.

Technical breakdown

Silent execution on require(): why install-time controls miss it

The loader in each package fires when the module is required, not when it is installed. That distinction matters because many supply chain controls focus on postinstall scripts, dependency diffing, or registry policy, while this campaign avoids those paths entirely. The malicious code spawns a detached child process, suppresses standard output and error, and allows the parent process to continue normally. This pattern makes the package appear functionally legitimate while the background process retrieves and executes the real payload.

Practical implication: monitor runtime module execution and child process creation, not just package installation events.

Multi-channel payload delivery and staged C2

The campaign uses several hardcoded delivery channels, each returning a different stage-2 payload. That design gives the operator resilience and supports multiple tenants or campaigns on shared infrastructure. The loader fetches obfuscated content, then executes it dynamically with constructor-based evaluation, which means static signatures are less useful than behavioural detection. In practice, this is a staged malware architecture: the package is only the delivery shell, while the payload can be swapped without changing the initial package footprint.

Practical implication: treat dynamic code evaluation and outbound retrieval from package processes as high-risk behaviours deserving alerting.

Secret theft through developer trust boundaries

The decoded payload targets browser credentials, crypto wallet extensions, local files such as .env, and in some variants reverse shell activity with clipboard monitoring. That combination shows why secrets management and developer endpoint security now overlap. A malicious package can inherit the permissions and context of a developer workstation or CI runner, then use those privileges to steal credentials that were never intended to leave the environment. This is a supply chain attack on access, not only on code integrity.

Practical implication: reduce the blast radius of developer and CI identities that can reach secrets, wallets, or source-controlled credentials.

Threat narrative

Attacker objective: The attacker’s objective is to turn trusted npm dependencies into a covert credential-harvesting and secret-exfiltration channel that reaches developer and CI environments.

1. Entry occurred when developers or build systems installed seemingly legitimate npm packages that blended into dependency trees through names like chai-as-* and utility-style aliases.
2. Credential access occurred when the stage-3 payload targeted browser-stored credentials, wallet extensions, and local secrets such as .env files from the compromised execution context.
3. Impact occurred when stolen secrets, sessions, and files could be exfiltrated to operator-controlled infrastructure and reused for follow-on access across development environments.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• GitHub Dependabot Breach — GitHub Dependabot tokens stolen and abused to push malicious commits to repositories.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Package trust has become a non-human identity problem. npm packages, build jobs, and loader processes now behave like identities with access, but many programmes still treat them as software artefacts rather than governed actors. That gap matters because the package may not be malicious at publish time, yet still execute malicious code at runtime. The governance conclusion is simple: if a dependency can execute and reach secrets, it needs identity-style control boundaries, not only provenance checks.

Silent runtime execution is the real control gap exposed here. This campaign succeeded by avoiding install-time hooks and waiting for require() to trigger the loader. That means the failure is not just malicious publication, but overreliance on package installation as the moment of risk. Security teams should recognise this as a detection and authorisation boundary problem. The practical conclusion is to move inspection closer to runtime execution and process lineage.

Secrets exposure is now the measurable business outcome of supply chain compromise. The payload’s value is not the package itself but the credentials, files, and sessions it can reach once it lands in a developer or CI context. That is where NHI governance intersects with AppSec: tokens, API keys, and environment secrets are the real standing privilege. Standing secret exposure window: when credentials remain valid after compromise and are still usable long after detection. The practitioner conclusion is to shorten exposure windows and narrow identity scope.

The campaign also shows why package provenance and behavioural trust must be separated. A package can look legitimate through naming, README language, and metadata while still hosting a detached loader and obfuscated payload retrieval. That weakens any governance model that equates publication legitimacy with operational trust. For identity and security teams, the answer is to evaluate dependency trust as a lifecycle problem, from publication through runtime execution and revocation.

AI-adjacent package ecosystems are already expanding the attack surface. Even when the immediate target is not an AI system, the same dependency ecosystems increasingly support AI tooling, developer assistants, and code-generation pipelines. That means a package compromise can cascade into NHI exposure across model-adjacent infrastructure. The practitioner conclusion is to extend supply chain scrutiny to every package that can touch code, secrets, or automated build paths.

From our research:

• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded, according to The State of Secrets Sprawl 2026.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets Sprawl 2026.
• For a deeper threat pattern view, see The 52 NHI breaches Report for how exposed credentials and third-party access repeatedly drive real-world compromise.

What this signals

Secret sprawl is the enabling condition behind supply chain compromise. The jsonspack campaign shows that malicious packages do not need to steal passwords from a login screen if they can harvest them from the developer environment itself. That makes secrets hygiene a first-line control for software supply chain resilience. Teams should pair dependency controls with the OWASP Non-Human Identity Top 10 and NIST SP 800-53 Rev 5 Security and Privacy Controls to reduce credential exposure across build and runtime paths.

The operational signal for practitioners is that package risk is now a runtime governance issue. If a dependency can spawn processes, reach the network, and touch local files, it must be treated like an identity-bearing workload with bounded permissions. The practical shift is to review which developer tools, CI runners, and automation identities can access browser sessions, environment secrets, and source-controlled credentials.

Standing secret exposure window: the time between secret theft and revocation now determines downstream compromise more than the initial package event. Once a package can lift usable secrets, the attacker’s window stays open until those credentials are rotated and the affected environments are cleaned. This is why programmes should align detection with automated revocation and secret scoping, not just alerting.

For practitioners

• Instrument runtime dependency execution Log module require() activity, detached child process creation, and dynamic constructor-based evaluation in Node.js build and runtime environments.
• Treat package metadata as insufficient trust evidence Require additional approval for packages that mimic common libraries, reuse popular branding, or ship loader code that immediately hands control to another process.
• Reduce secret reach from developer and CI identities Scope tokens, .env access, and build credentials so a compromised package cannot reach more than the minimum necessary secrets or files.
• Block known malicious package behaviour patterns Alert on packages that suppress stdout and stderr, spawn detached processes, or retrieve executable payloads from external channels after require().
• Rotate exposed secrets as a response trigger When package compromise is confirmed, revoke any developer, CI, or automation secrets that may have been present in the affected environment, including browser-saved credentials if workstations were involved.

Key takeaways

• The campaign shows that npm packages can function as covert non-human identities, with runtime behaviour that bypasses install-time trust checks.
• Panther recorded 27 malicious packages and 3,739 downloads, which is enough scale to turn package-level abuse into real credential exposure risk.
• Teams need runtime controls, secret revocation, and narrower identity scope for developer and CI environments if they want to limit the blast radius of supply chain compromise.

Key terms

• 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.
• Supply Chain Loader: A supply chain loader is the first-stage code delivered through a trusted package or dependency that pulls down or starts the real malicious payload. It often looks harmless on its own, but it creates the execution bridge between a legitimate distribution channel and attacker-controlled behaviour.
• Secret exposure window: A secret exposure window is the period between when a credential becomes visible to an attacker and when it is detected, revoked, or rotated. In CI/CD environments that window can be extremely short, which is why detection speed and identity-linked revocation matter as much as storage hygiene.
• Runtime Dependency Risk: Runtime dependency risk is the gap between what a software manifest says will run and what a live workload is actually executing. It matters because malicious or altered packages can behave differently at runtime, especially when they touch secrets, spawn processes, or call external endpoints.

What's in the full report

Panther's full analysis covers the operational detail this post intentionally leaves for the source:

• Campaign attribution and clustering logic across the 27 malicious npm packages, including how the shared author metadata was used to correlate activity.
• Loader-level source excerpts for each variant, including the require()-triggered child process pattern and the inline IIFE exception.
• Decoded stage-3 payload analysis, including the browser credential, wallet, file exfiltration, and reverse shell components.
• Detection logic examples and telemetry-based rules for identifying the campaign in enterprise environments.

👉 The full Panther post covers loader variants, payload behaviour, and detection logic in detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle control. It helps security and identity practitioners translate identity principles into operational boundaries for modern software supply chains.