Summary
Togoder Security scanned the npm package why-is-node-running@3.2.1 on Oct 6, 2026. An AI review of 3 source files produced 4 medium, 4 low severity findings. The overall verdict is medium: the findings flag risky but common patterns (dynamic code, unsafe defaults, broad file or network access) rather than confirmed malware.
Findings 8
User-controlled command execution
NPS-6034373097EB
The program name and arguments are taken directly from process.argv and passed to spawn without validation or sanitization. This allows arbitrary command execution (e.g., 'node cli.js malicious_script.js' or even 'node cli.js --eval ...' if the user supplies flags). While this is the intended purpose of a launcher, it can be exploited if the CLI is invoked by other software with untrusted input.
Dynamic module loading via --import flag
NPS-2C1166C05057
The script injects an 'include.js' module via the Node.js --import flag when spawning the child process. This causes the module to be loaded and executed before the target program runs. If include.js is malicious, it could perform arbitrary actions (data exfiltration, credential harvesting, etc.) with the same privileges as the user. The script itself only references a local file, but the behavior is a code injection mechanism.
Spawning processes
NPS-C8243046BE6A
The script uses child_process.spawn to launch a new Node.js process, which is a common pattern for wrappers but can be abused for malicious execution. The spawned process is a Node.js runtime with a user-supplied program and arguments, effectively acting as a command launcher. This is not inherently malicious but represents a security-relevant capability.
Process signal handler / diagnostic hook
NPS-75345273BE9E
The file registers handlers for SIGINFO and SIGUSR1 that call whyIsNodeRunning() from './index.js', and logs the PID to the console. While this itself is not malicious, it executes at import time and imports an unspecified local module. The actual behavior depends entirely on index.js, which is not provided. If index.js performs data exfiltration, credential harvesting, shell execution, or other malicious actions, it would be triggered by sending SIGUSR1/SIGINFO to the process. The console.log leaks the process PID, which could aid an attacker in targeting the running process.
Top-level code execution on import
NPS-EC562FF08961
The code runs at module load time, attaching signal listeners and printing to stdout. Side effects on import are generally undesirable and can be abused as an activation mechanism for hidden functionality in a dependency.
Runtime hooking / async resource interception
NPS-D7763374692C
The code uses node:async_hooks createHook to intercept all async resource initialization and capture full stack traces for every async operation. This is global runtime instrumentation that persists for the lifetime of the process. While this is the intended functionality of a diagnostic tool, it constitutes broad runtime interception of all async activity in the host application.
Import-time side effects
NPS-CC14E62CE04E
hook.enable() is called at module top-level, meaning simply importing this module globally hooks async resource creation in the host process. This is an import-time side effect that modifies global runtime behavior without explicit user opt-in beyond the import.
File system access outside package scope
NPS-506C7F6B3266
The printStacks function calls readFileSync on file paths derived from stack traces. While this is intended to display source code context for debugging async handles, it reads arbitrary files referenced in stack traces. This is a legitimate debugging feature but does access files outside the package scope based on runtime stack data.
Files reviewed
| File | Verdict | What the reviewer saw |
|---|---|---|
| cli.js | medium | The script is a wrapper that spawns a Node.js process with a user-supplied program and an injected import module, which could be abused for command execution or module injection, but no overt malicious patterns like data exfiltration or credential theft are present. |
| include.js | medium | The file itself only sets up debug signal handlers, but it imports an unspecified index.js executed on import and exposes the PID, creating a potential activation vector for malicious behavior in that module. |
| index.js | medium | This appears to be a legitimate debugging utility (similar to why-is-node-running) that uses async_hooks to track open handles, with only minor concerns around broad runtime instrumentation and reading files referenced in stack traces. |
Frequently asked questions
Is why-is-node-running safe to use?
No confirmed malware was found in why-is-node-running@3.2.1, but the review flagged 4 medium, 4 low severity findings for risky patterns worth checking before you rely on it.
Does why-is-node-running contain malware?
No malware was identified in why-is-node-running@3.2.1 when Togoder Security scanned it on Oct 6, 2026. A new version can still introduce malicious code, so scan the exact versions in your lockfile.
How was why-is-node-running checked?
Togoder Security downloaded the published npm package and had an AI model read its 3 source files, looking for install scripts, credential access, network exfiltration, obfuscation, backdoors and crypto-wallet theft. The results are cached by file hash and shown here.
How do I scan why-is-node-running together with the rest of my dependencies?
Upload your lockfile at https://security.togoder.click/scan or call the API documented at https://security.togoder.click/api-docs. Files that have already been scanned, like the ones in why-is-node-running@3.2.1, cost nothing.