What breaks when a malicious npm package runs at require() time?

Why Require-Time Execution Breaks the Package Boundary

The key breakage is that package installation is no longer the moment that matters most. A malicious npm package can execute as soon as it is loaded, which means the attack surface shifts into ordinary application startup, test runs, and build steps. That undermines any assumption that “installed but not run” is a safe state.

At require() time, the package is executing inside the host process, often with the same environment, filesystem visibility, and network reach as the application itself. That is why a seemingly normal dependency can act more like embedded code than a passive library.

Once you treat require-time behavior as part of execution, the package boundary becomes a trust boundary only in theory. In practice, the dependency can observe the runtime context, influence control flow, and leave behind artifacts before the application’s own security checks or business logic have a chance to start.

What the Attacker Can Do Before Your App Meaningfully Starts

A malicious package loaded through require() can fingerprint the host, enumerate environment variables, inspect local files, and probe for tokens, keys, or config material that developers assume are only used later in the process. It can also decide whether to stay quiet, delay, or tailor its behavior to the machine it lands on.

Because the code runs in the caller’s process, it can preserve normal-looking return values while performing side effects in parallel. That makes detection harder: the application may continue working, logs may look ordinary, and the compromise can appear to be just another dependency import unless defenders inspect the startup path closely.

Persistence is the other major break. A package that runs early can drop files, modify startup artifacts, alter configuration, or plant follow-on execution paths that survive beyond the initial import. For an example of how npm malware uses early execution to steal secrets and spread, see Shai Hulud npm malware campaign and Nx s1ngularity attack 2025.

Why This Matters for Supply Chain Trust and Dependency Review

require() time execution is dangerous because it invalidates a common review habit: checking only the package’s declared features or install-time behavior. A dependency may look harmless in a code scan, yet still execute meaningful logic the moment another module imports it. That is especially relevant for transitive dependencies, where the affected package may never have been consciously chosen by the application team.

This is also why package provenance, maintainer trust, and update hygiene matter more than many teams expect. If you accept a package into the runtime path, you are not just trusting its API surface, you are trusting every code path that can run during module loading. The OpenSSF ecosystem is a useful reference point for supply chain hardening practices, and the threat is mirrored in incidents where malicious npm packages exfiltrated secrets from developer environments.

For practitioners, the practical lesson is that a package can be both a software dependency and an execution vector. That means source review, pinning, integrity controls, and dependency replacement decisions need to account for runtime effects, not just the advertised functionality of the library.

Risk and Threat Considerations

The main risk is that the attacker gets code execution in a place teams mentally treat as low-trust but not yet active. Once require() fires, the package can operate before many endpoint, application, or pipeline controls have a chance to distinguish legitimate startup from abuse. That creates a high-value path for secret theft, tampering, and silent persistence.

Failure mechanism: The package executes inside the application process at import time, so hostile code can read secrets, alter state, or plant follow-on execution while still returning a valid module object and avoiding obvious functional failure.

Impact: Defenders may miss the compromise because the application appears to start normally, but the attacker can already have stolen credentials, modified startup behavior, or established a durable foothold that survives routine dependency checks.

Practitioner Guidance

What to verify: Treat module loading as an execution event. Verify which packages run code on import, which transitive dependencies they pull in, and whether startup paths touch secrets, network calls, or filesystem writes before the app’s own controls initialize.

Common mistake: Reviewing only install scripts and ignoring require-time behavior. A package can be inert during installation and still be fully malicious the moment another module imports it.

Decision rule: If a dependency can access production secrets, build credentials, or developer tokens during startup, treat it as a runtime trust decision, not a library choice. Prefer dependency reduction, integrity enforcement, and isolation when the package boundary cannot be made observable.

Practitioner takeaway: The important boundary is not “installed versus not installed”, it is “imported code versus controlled code”, and require() time moves that boundary into the hottest part of the process.

Related resources from NHI Mgmt Group

• What breaks when a malicious npm package runs inside SAP build workflows?
• What breaks when a malicious npm package can read developer secrets during install?
• What breaks when a malicious package runs during dependency installation?
• What breaks when malicious npm packages are reviewed only at publish time?