Import-time npm malware shows why scripts-only defences fail

At a glance

What this is: Xygeni’s analysis shows 20 npm packages that ran malware on import rather than through install hooks, making scripts-only defences ineffective against the initial execution path.

Why it matters: IAM and software supply-chain teams need to treat import-time code execution as a governance gap because build and review controls often assume the risk starts at install, not at module load.

By the numbers:

• 20 npm packages published across two days in late July and early August 2026 presented themselves as internal libraries but executed malicious code on import.
• The payload retrieved a third binary that was several megabytes in size, with examples ranging from 4.3 MB to 13.3 MB.

Context

The security gap here is simple: many software controls assume malicious package behaviour happens during installation, but modern supply-chain malware can wait until a module is imported. That matters because import-time execution can happen inside a build, test, or bundling step after the package has already passed install-time checks.

The identity and access angle is indirect but real. A package that runs on import can reach cloud endpoints, local credentials, telemetry controls, and other runtime trust points before teams have a chance to verify what was actually loaded. For IAM and NHI programmes, this is a reminder that software distribution controls and credential governance are now part of the same attack surface.

This case is typical of supply-chain abuse that uses normal packaging behaviour as the trigger, not an exotic exploit chain.

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 scripts-only defences fail against supply-chain malware?

A: Because they assume the dangerous behaviour happens in preinstall, install, or postinstall hooks. If the package calls malicious code from its main module, those controls never fire. Security teams need package-level review, behavioural monitoring, and dependency policies that examine import-time effects as well as installation events.

Q: What are the signs that an npm package may be behaving like a dropper or data exfiltration payload?

A: Common warning signs include obfuscated code, repeated package descriptions across unrelated projects, lifecycle hooks that invoke Node automatically, and outbound requests soon after install. Additional indicators are enumeration of hostname, username, working directory, or package metadata. When several of these appear together, teams should assume the package is suspicious and investigate immediately.

Q: How should security teams respond when a package suppresses telemetry and security tools?

A: Treat the package as a live compromise path, not just a bad dependency. Contain affected build and runtime hosts, preserve process and network telemetry before it is overwritten, and search for import-time execution on similar packages. Telemetry suppression means the window for reliable evidence is short, so triage has to start from the first observed import event.

Technical breakdown

Why import-time execution bypasses install-hook controls

npm lifecycle defences such as --ignore-scripts only suppress preinstall, install, and postinstall hooks. They do not stop code that executes because application logic imports a package entry point. In the case described, the final line of index.js explicitly required a local _polyfill module, which meant the payload ran the first time the package was loaded by application code, a test, or a build step. That is a different execution trigger from package installation, so install-time hardening does not fully cover the threat surface.

Practical implication: Treat module import as an execution event and review package entry points, not just lifecycle scripts.

How staged loaders hide behind normal runtime behaviour

The first stage was a small JavaScript wrapper that fetched a platform-specific executable from external infrastructure, wrote it to disk under a randomised name, set execute permissions, and launched it detached from the parent process. That loader pattern gives operators flexibility across Windows, Linux, and macOS while keeping the initial package lightweight. It also decouples visible npm content from the real payload, which is why static package inspection alone can miss the operational impact. Staging also allows the operator to switch delivery methods, including DNS TXT records when HTTP retrieval is blocked.

Practical implication: Inspect outbound retrieval, temp-file writes, and detached child processes as part of package risk review.

Why AMSI, ETW, and endpoint enumeration matter in the second stage

The loader behaviour described in the article shows a common post-execution pattern: enumerate endpoint security products, check for analysis-environment usernames, and suppress telemetry before running the main payload. AMSI is Windows' content-scanning interface for in-memory script inspection, while ETW records event telemetry that defenders often rely on for detection. Patching those interfaces in memory reduces the visibility of the payload after it has already launched. The result is not only stealth, but also a narrower forensic trail for defenders to reconstruct later.

Practical implication: Correlate package execution with telemetry suppression indicators, especially AMSI, ETW, and anti-analysis checks.

Threat narrative

Attacker objective: The objective was to establish stealthy code execution from a trusted package import and then run a persistent, in-memory payload chain across supported platforms.

1. Entry occurred when a consumer imported the npm package and the final line of index.js invoked _polyfill.js instead of waiting for an install hook.
2. Credential and telemetry suppression followed as the loader enumerated endpoint security tools, checked for analysis usernames, and patched AMSI and ETW in memory.
3. Impact came when the loader fetched a third-stage binary, decrypted it in memory, and executed it without leaving a normal on-disk artefact.

Breaches seen in the wild

• LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.
• PyPI secrets exposure 2023: Researchers found 3,938 unique secrets in published PyPI packages, 768 still valid; a new release or yank does not remove them.

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 now a software governance problem, not just a malware trick. Build and install controls are still necessary, but they do not address code paths that execute on module load. That creates a blind spot in software supply-chain governance because package trust is being inferred from install behaviour rather than runtime behaviour. Practitioners should treat entry-point auditing as part of supply-chain assurance, not a niche code review task.

Scripts-only hardening leaves a false sense of safety in JavaScript ecosystems. The article shows that a package can look conventional, avoid lifecycle hooks, and still execute malicious code the moment it is imported. That means the control boundary must expand from install-time policy to package content, import behaviour, and downstream runtime effects. The practical conclusion is that supply-chain control has to be aligned to actual execution semantics, not packaging conventions.

Import-triggered loaders create an identity and access shadow zone. Once a package can execute at import time, it can reach local tokens, cloud session material, and telemetry suppression points before the host security stack understands what happened. That is especially relevant for NHI governance because runtime automation and build tooling increasingly depend on secrets and ephemeral credentials. The practitioner takeaway is to govern packages as execution-bearing assets, not passive dependencies.

Endpoint-security evasion is part of the delivery design, not an afterthought. The Windows loader’s enumeration of security products, anti-analysis checks, and telemetry tampering show a mature intent to survive in managed environments. That matters because it means detection logic that waits for overt malware actions will lose the race. Teams need to assume the package itself may be the initial execution vehicle and should validate behaviour at load time, not after compromise is obvious.

What this signals

Package governance has to move closer to runtime reality. When a dependency can execute at import time, the control question is no longer whether install hooks are blocked, but whether code review, build policy, and dependency monitoring are aligned to actual execution paths.

Import-time execution gap: this is the mismatch between packaging controls and runtime behaviour, and it is exactly where supply-chain malware now hides. Teams should assume that a benign-looking package may still act as a loader, retrieval client, or telemetry suppressor once imported.

For identity and access programmes, the broader lesson is that secrets and credentials are exposed to application code earlier than many governance models assume. That makes dependency trust, credential scoping, and host telemetry part of the same control plane.

For practitioners

• Audit package entry points for hidden execution Review package main files, index.js endings, and any bottom-of-file require patterns that invoke local modules after export declarations. Focus on dependencies that look like utilities but execute code during import.
• Extend dependency policy beyond lifecycle scripts Do not rely on --ignore-scripts as a complete supply-chain control. Add checks for import-time execution, unusual temp-file writes, detached child processes, and runtime network retrieval during package load.
• Block or alert on staged binary retrieval from packages Flag JavaScript dependencies that fetch platform-specific executables, assemble hostnames at runtime, or fall back to DNS-based delivery. Those behaviours indicate the package is acting as a dropper rather than a library.
• Hunt for telemetry tampering and endpoint enumeration Correlate package imports with AMSI, ETW, and security-product enumeration, especially where analysis-environment usernames or anti-debugging checks appear in the same execution chain.

Key takeaways

• The central failure in this case is not a missing install hook check, but a governance model that stopped at installation and ignored module import as an execution trigger.
• The package chain shows how a small initial payload can stage endpoint enumeration, telemetry tampering, and in-memory execution without leaving the normal disk artefacts defenders expect.
• Teams that want meaningful supply-chain resilience need controls for entry-point review, staged-binary detection, and telemetry-aware response, not just lifecycle-script blocking.

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.
• Loader: A loader is malware whose main job is to retrieve, decrypt, inject, or launch a second-stage payload. In these campaigns, loaders are not the final objective. They are the mechanism that turns an initial click into remote access, persistence, or data theft.
• Telemetry Suppression: Telemetry suppression is the deliberate reduction, deletion, or distortion of security evidence so defenders cannot reconstruct what happened accurately. It includes log deletion, metadata rewriting, and hiding victim identifiers, all of which degrade investigation quality and slow containment.
• Package Dropper: A software package that exists mainly to deliver another payload rather than provide the functionality described in its manifest or README. Droppers often hide retrieval, execution, and persistence behaviour behind normal dependency mechanics.

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 identity governance to broader security operations and software risk.