Import-time npm supply chain malware is bypassing install-hook defenses

At a glance

What this is: Xygeni shows that npm malware can execute at import time, bypassing install-hook defenses and reappearing quickly under new package names.

Why it matters: This matters because dependency controls that focus on install scripts miss module-load execution, which can compromise developers, CI runners, and downstream environments before any obvious alert fires.

Context

Import-time malware turns a trusted dependency load into an execution path. In npm, that means code can run when a package is required or imported, even if package.json has no preinstall or postinstall hook to inspect. The governance gap is not just package admission, but what a dependency does at runtime on developer and CI hosts.

This article is fundamentally about supply-chain abuse, but it has a clear identity angle because the attack exploits application dependencies, build accounts, and the network reach available to developer and automation identities. Once a utility package is trusted and imported, the malicious code inherits that trust boundary and can operate with the caller's privileges.

Xygeni's analysis treats the campaign as a live operator pattern rather than an isolated malicious package. That is typical of modern package-layer attacks: the names change, but the staging infrastructure and execution model persist long enough to matter operationally.

Key questions

Q: What breaks when npm security controls only scan install scripts?

A: They miss malicious code that runs at import time inside normal module initialisation. In this pattern, a package can avoid preinstall and postinstall hooks entirely, yet still execute a payload as soon as application code loads it. That means script-only scanning creates a false sense of safety and leaves build, test, and developer environments exposed.

Q: Why do import-time npm trojans create such a persistent risk?

A: They persist because the malicious code is triggered by ordinary package use, not by a special installer hook. That makes the attack harder to distinguish from normal library behaviour and lets the operator repackage the same payload under new names while keeping the same network infrastructure.

Q: Where do teams usually miss hidden execution in package dependencies?

A: They usually stop at direct dependencies and package metadata, then miss carrier packages and transitive imports that trigger the real payload. The safer approach is to trace what code executes when modules are loaded, especially in small utilities that are widely reused across projects.

Q: How should security teams respond when a package starts reaching out to unknown domains at load time?

A: Treat it as a compromise signal, not as a harmless update check. Isolate the host or pipeline, block the destination at DNS and egress layers, search for the same indicator across lockfiles and logs, and assume the imported code may have executed with the caller's privileges.

Technical breakdown

Why import-time code execution bypasses install-hook scanning

Install-hook scanning looks for scripts declared in package metadata, especially preinstall and postinstall handlers. This campaign avoids that control by placing malicious logic in the module entry point, so the payload runs when the package is imported, not when it is installed. That means a clean install event can still lead to execution later when a build step, test, or application load path touches the module. In practical terms, the attack hides inside normal JavaScript initialization and is hard for tooling that only inspects lifecycle scripts to see.

Practical implication: Treat module-load behaviour as a separate inspection target, not a subset of install-script review.

How a carrier package widens the blast radius

A carrier package is a benign-looking dependency that imports a malicious sibling, causing the payload to execute transitively. In this case, a logger package pulled in the trojaned terminal package and triggered its code without the project naming the malicious package directly. That pattern matters because defenders often review only explicit top-level dependencies, while transitive imports can bring hidden execution into the tree. It also complicates allow-listing, because the visible package may look harmless on its own while acting as a delivery path for the real payload.

Practical implication: Inspect transitive dependency chains and not just the packages your team intentionally added.

Why remote staging makes the endpoint the durable indicator

The second-round packages used a one-line stager that fetched remote code and executed it, passing the command-and-control address through an environment variable. This shifts the most stable indicator from the package name to the network destination, because the retrieved payload can change without republishing the package. It also means takedown at the registry does not necessarily neutralise the operator if the infrastructure remains intact. For defenders, the important distinction is between package reputation and operator infrastructure, because the latter survives renaming much better.

Practical implication: Build egress detections around suspicious staging domains and remote shell patterns, not only package deny-lists.

Threat narrative

Attacker objective: The attacker wants reliable execution on developer and CI hosts, plus a reusable command-and-control channel that survives package takedown and renaming.

1. Initial access begins when a developer, build job, or CI runner imports the trojanized npm package and executes module-level code.
2. Credentialed execution then fetches a remote shell script and passes a tracked command-and-control endpoint into the staging process.
3. The operator can then run arbitrary commands through the downloaded payload and maintain contact with the host over the same infrastructure after republishing under new names.
4. Impact is host compromise on any Unix-like system that loads the package, with exposure extending to credentials, build context, and network-reachable resources.

Breaches seen in the wild

• LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.

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

Import-time execution is the control failure this campaign exposes: the industry has treated npm install hooks as the primary supply-chain inspection point, but that assumption misses module-level code entirely. A dependency can be clean at install and still become active at first import, which is where many build and runtime trust decisions actually happen. Practitioners should move inspection from package metadata alone to the behaviour of code at load time.

Carrier packages create a governance blind spot for transitive trust: teams that only review direct dependencies will miss packages that exist mainly to pull in a second malicious component. That is especially relevant for JavaScript ecosystems, where small utilities can sit deep in application and CI dependency graphs. The right control question is not only what was installed, but what code is now reachable through the import tree.

Remote staging makes network telemetry the most durable evidence: once the payload is fetched from an external host, registry takedown becomes only one part of the response. The enduring signal is the staging domain and any repeatable outbound pattern associated with it. Practitioners should treat egress visibility as a supply-chain control, not just a perimeter control.

Module-load malware is a supply-chain identity problem as well as a code problem: the package inherits the caller's execution context, which often means developer or CI identity with broad filesystem and network reach. That creates a trust boundary failure between package provenance and runtime authority. Security teams should treat dependency import as a privilege-bearing event, not a passive file read.

Import-time malware deserves its own named concept, dependency-load execution drift: the security model assumes meaningful checks happen at install, while the actual execution occurs later when the package is loaded. That drift between approval time and execution time is what makes these campaigns so resilient. The practical answer is to align scanning, sandboxing, and egress policy with load-time behaviour, not just installation events.

What this signals

Dependency-load execution drift: the control gap here is the distance between package approval and the moment code actually runs. When security review stops at install-time metadata, runtime import becomes the real attack surface, especially in build pipelines that execute trusted-looking utility libraries.

The practical lesson for practitioners is to treat transitive imports, not just explicit installs, as execution paths with identity and privilege implications. A CI runner or developer workstation that loads a malicious package can hand the attacker the same outbound network reach and filesystem access as the legitimate job.

Runtime egress control is now part of supply-chain defence, not an optional network add-on. If a dependency can fetch and execute remote code on first import, the fastest containment is to prevent that outbound session from completing.

For practitioners

• Audit module-load behaviour in dependency trees Scan packages for top-level exec calls, outbound network calls, and code that runs during require or import, especially in utility modules that appear harmless.
• Block suspicious staging domains and shell patterns Add DNS and egress detections for remote script loaders such as curl piped to sh, and alert on repeat use of the same command-and-control host across package names.
• Review transitive dependencies as potential execution paths Trace carrier packages that exist only to pull in other modules, and treat any dependency chain that imports obscure utilities as high risk until validated.
• Harden build and developer hosts against post-load compromise Assume any imported trojan can execute with the caller's privileges, then restrict outbound network reach and rotate credentials exposed on affected hosts.

Key takeaways

• This campaign shows that npm malware can evade hook-based screening by moving execution from install time to import time.
• The same operator reused command-and-control infrastructure across package renames, which makes network indicators more durable than package names.
• Defenders need to inspect module entry points, transitive imports, and egress behaviour together if they want to catch dependency-layer malware early.

Key terms

• Import-time execution: Import-time execution is code that runs when a Python module is loaded rather than when a user deliberately calls a function. That behaviour matters in security reviews because it can trigger secret access, network calls, or persistence before an application has meaningfully started operating.
• Carrier package: A package whose main role is to pull in another malicious dependency and trigger it transitively. Carrier packages increase reach because teams may trust the wrapper while never directly installing the trojan, making dependency graphs and import paths central to security review.
• Command-and-Control Endpoint: The remote server an attacker uses to issue commands, stage payloads, or receive output from a compromised host. In dependency attacks, a stable endpoint can outlast package renames and serve as the most durable indicator of operator reuse.
• Transitive Dependency: A transitive dependency is a package that your software uses indirectly through another library rather than calling it directly. These dependencies often hide in Java estates, which makes visibility and runtime validation necessary to understand what code is actually present and active.

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. It is designed for practitioners who need to connect identity controls to broader security operations and governance decisions.