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

At a glance

What this is: This is a supply-chain malware analysis showing that trojanized npm packages can execute at import time and survive takedown through fast rebranding and reused infrastructure.

Why it matters: It matters because many software supply-chain controls still focus on install scripts, while this campaign executes when code is imported, reaching developer workstations and CI systems before traditional checks fire.

By the numbers:

• 74 minutes.
• Round one was unpublished on 2026-07-05 at 14:14 UTC.

👉 Read Xygeni's analysis of the npm import-time malware campaign

Context

Import-time malware is a supply-chain problem because the malicious code runs when a package is loaded, not when it is installed. That difference matters in npm environments where scanners, review workflows, and policy gates often concentrate on package.json hooks and install-time behaviour. In this case, the relevant identity angle is the trust relationship created by dependencies, maintainers, and transitive package imports.

The article shows a rebrand-and-reuse pattern that is increasingly common in dependency compromise: useful code is mixed with a small stager, then the package is republished under new names after removal. For IAM, PAM, and NHI practitioners, the governance lesson is that software supply chains now behave like distributed identity systems, with package trust, maintainer continuity, and downstream execution all needing control.

The starting position is not atypical. Many engineering teams still assume that if install scripts are disabled, the dependency path is safe enough. This campaign demonstrates that assumption is too narrow.

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 transitive dependencies create more software supply chain risk than direct packages alone?

A: Transitive dependencies hide exposure inside nested libraries that are often missed by top-level package reviews. If defenders only track direct components, they can miss the code attackers are most likely to exploit. A dependency-aware inventory reduces that blind spot and gives teams a realistic view of what is actually present in production.

Q: How should security teams detect rebranded malicious packages?

A: They should look for infrastructure reuse, payload behaviour, and transitive import patterns instead of relying on package names alone. When the same command-and-control endpoint or download host appears across renamed packages, that is a stronger indicator than a simple denylist entry. Behavioural detection survives republishing better than static name blocking.

Q: Who should be accountable when compromised npm packages spread through CI and developer systems?

A: Accountability should sit with the teams that own workflow identity, dependency governance, and secret management together, because the failure spans all three. Security, platform engineering, and application owners need a shared response model for package poisoning, credential rotation, and publishing control. That shared ownership is what prevents a supply-chain issue from becoming an open-ended identity incident.

Technical breakdown

Why import-time execution bypasses install-hook scanning

In npm, a package can execute code as soon as it is imported, whether through CommonJS require() or ESM import. That means a malicious module-level child_process.exec call does not need preinstall or postinstall hooks to run. Security tooling that inspects only package scripts will miss it because the payload sits in ordinary source files and behaves like normal module initialisation. The result is a control gap between packaging-time checks and runtime execution, especially inside CI pipelines that resolve dependencies before running application code.

Practical implication: inspect dependency source and runtime behaviour, not only package scripts.

How carrier packages widen the blast radius in npm ecosystems

A carrier package is a benign-looking dependency that imports the trojanised package transitively. In this pattern, one utility package declares another as its dependency and triggers the payload through a normal import path. That design widens exposure because a project may never reference the malicious package name directly. Transitive trust is therefore part of the attack surface, not just direct installation. For defenders, the key issue is that dependency graphs can hide execution paths that appear harmless during review but activate at load time.

Practical implication: trace transitive imports and treat obscure utility chains as execution paths, not just dependencies.

Why reusing command-and-control infrastructure is the durable indicator

The campaign reused the same tracker.bvgroup.co endpoint across both rounds, even after the package names changed. That matters because names are cheap to rotate, while infrastructure reuse creates a more durable detection signal. The article also shows a staged payload model, where a package only fetches a remote shell script and then passes a tracking endpoint into stage two. This decouples the registry artifact from the live payload and lets the operator change behaviour without republishing the same code.

Practical implication: block and alert on infrastructure indicators and remote stagers, not only package names.

Threat narrative

Attacker objective: The attacker wants persistent remote execution on developer and CI hosts through a dependency trust path that can be republished faster than takedown can stop it.

1. Entry occurs when a developer or CI job imports a trojanised npm utility package, triggering module-level execution without any install hook.
2. Escalation follows when the package fetches a remote shell script and passes operator-controlled tracking data into the downloaded stage two payload.
3. Impact occurs when the stage-two code runs with the host user's privileges, establishes command-and-control, and extends compromise into build and development environments.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• LiteLLM PyPI package breach — LiteLLM PyPI supply chain attack, credentials stolen from users.

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

NHI Mgmt Group analysis

Import-time malware is the next control gap in dependency security: install-hook scanning was built for preinstall and postinstall abuse, but this campaign executes at module load. That shifts the defensive problem from package metadata to code-path inspection and runtime control. Teams that still equate dependency hygiene with hook scanning are protecting the wrong boundary. Practitioners should treat import-time execution as a first-class supply-chain threat.

Package identity is not a sufficient trust signal: the same operator re-used infrastructure after renaming the packages, which means name-based denylisting ages out immediately. The enduring trust anchor is no longer the package label but the combination of maintainer behaviour, transitive execution, and outbound infrastructure. In governance terms, this is a software identity problem as much as a malware problem. Practitioners should base trust decisions on observable execution and network patterns.

Carrier packages expand attack reach across the software supply chain: one benign-looking wrapper can import the trojan and spread compromise into projects that never install the malicious package directly. This is a classic transitive trust failure and it should be treated as part of dependency governance, not a separate anomaly. The named concept here is import-path compromise: malicious code that activates only when normal application loading reaches it. Practitioners should model dependency graphs as runtime paths.

Network infrastructure is the strongest reuse signal in fast-moving campaigns: tracker.bvgroup.co survived both rounds, while package names did not. That means detection programmes need durable indicators that outlast registry churn and rebranding. The broader market implication is that software supply-chain defence is moving toward behaviour, egress, and provenance rather than static blocklists. Practitioners should prioritise controls that survive repackaging.

Identity governance and supply-chain governance are converging: the attack relied on trusted publication rights, dependency relationships, and downstream execution privileges. Those are governance concerns familiar to IAM teams, even if the target environment is software delivery rather than workforce access. Where package maintainers, CI identities, and runtime execution are loosely controlled, compromise becomes easier to hide. Practitioners should align supply-chain policy with identity and privilege review.

What this signals

Import-time malware pushes dependency governance closer to runtime governance. Teams should expect more attacks that evade package-script scanning and instead trigger when application code loads libraries, which means build policy alone is not enough. Align dependency review with egress monitoring, provenance checks, and tighter control over CI identities.

Import-path compromise: this campaign shows how a benign wrapper can become the execution path for malicious code. For practitioners, that means transitive imports deserve the same scrutiny as direct dependencies, especially where package maintainers and runtime execution are loosely governed. The practical shift is to treat software loading as a trust decision.

Supply-chain defence will continue to favour indicators that outlive republishing. Package names are easy to replace, but reused domains, staging URLs, and command-and-control infrastructure are harder to hide. Practitioners should build detection around those durable signals and use them to drive faster containment when dependencies are reissued under new names.

For practitioners

• Scan for import-time execution paths Review dependency source for module-level exec, fetch, eval, or dynamic loading patterns in both ESM and CommonJS entry points. Prioritise packages that execute before application startup and do not rely on install scripts.
• Block reuse of campaign infrastructure Add DNS, proxy, and egress detections for tracker.bvgroup.co, remote.agyn.org, and related operator domains, then hunt for those indicators in historical logs.
• Trace transitive import chains Map packages that act only as carriers for other utilities, especially where a small wrapper imports another obscure dependency at load time. Treat those chains as execution paths and not just dependency relationships.
• Harden CI against dependency-triggered egress Run dependency review before build execution, restrict outbound network access during tests where possible, and alert on unexpected curl pipes to shell from package code.
• Rotate exposed credentials after package compromise If any workstation or pipeline imported the affected packages, rotate tokens and keys reachable from that host and review adjacent secrets that may have been available to the same environment.

Key takeaways

• This campaign shows that npm malware can bypass install-hook defenses by executing at import time, which changes where defenders need to look.
• The scale of the problem is not just five malicious packages, but the speed of reuse, with relaunch occurring 74 minutes after takedown using the same infrastructure.
• The most effective controls are source review, transitive import tracing, runtime egress monitoring, and rapid rotation of any credentials reachable from affected hosts.

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: Command-and-control is the communication channel an attacker uses to issue instructions to malware and receive results back from a compromised host. For XWorm, the channel is encrypted and used for session management, payload delivery, surveillance, and modular expansion of capabilities after compromise.
• Transitive trust: The hidden risk created when one trusted app inherits confidence from another trusted relationship. In SaaS environments, approving a third-party tool means trusting its hosting, storage, developers, and connected services, which widens the attack surface beyond the original login event.

What's in the full analysis

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

• Source code excerpts showing exactly how the import-time payload is embedded in both ESM and CommonJS entry points
• A round-by-round timeline of the neon-* and agn-* packages, including publication, takedown, and relaunch timing
• Indicators of compromise for proxy, DNS, and endpoint hunting, including the reused command-and-control infrastructure
• Package-level behavioural clues that help distinguish a harmless utility from a carrier package with hidden execution paths

👉 The full Xygeni post covers the package timeline, indicators of compromise, and payload mechanics 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 IAM foundations. It helps practitioners connect identity controls to the software supply-chain risks that modern engineering programmes inherit.