ts-node@10.9.2 security report

Uses createRequire() and require() to dynamically load a module from the dist directory. While this pattern is commonly used in ESM/CJS interoperability layers, dynamic require() can be abused to load arbitrary or computed modules and bypass static analysis. The file imports a local package-relative path, which limits the immediate risk, but the pattern warrants review.

The comment 'TODO why use require() here? I think we can just import' indicates the author is uncertain about the dynamic require usage. Unresolved dynamic loading patterns are a code smell and could hide future malicious changes if the required path is later altered.

The code imports internal Node.js primordials and internal bindings (e.g., node-primordials, node-internalBinding-fs). This is typical for tools that patch Node.js internals (like ts-node) but indicates deep integration that could break or be abused in future Node versions. Not malicious by itself.

The module executes top-level code (e.g., reading options, initializing caches) when imported. This is normal for a module loader but means any side effects (like reading environment options via getOptionValue) occur at import time. No malicious side effects observed.

The code performs extensive file system operations (stat, realpathSync, readPackage) to resolve modules. This is expected for a module loader but could be leveraged for reconnaissance (probing file existence) if the attacker controls the request paths. No direct exfiltration or credential harvesting is present.

The tryPackage function resolves the 'main' field of package.json to a file path without strict validation. If a malicious package.json contains a 'main' field like '../../etc/passwd', it could attempt to load arbitrary files. However, this is standard Node.js behavior and not a vulnerability introduced by this code. The code does not sanitize but relies on Node's resolution rules.

The code uses fs.statSync and fs.realpathSync to check file existence and resolve paths, including accessing node_modules directories and package.json files. This is typical for a module resolver, but excessive file system probing could be a concern if the input is untrusted.

The resolver uses process.versions.node and getOptionValue to adjust behavior based on Node.js version and command-line flags. This is standard, but it could be used to conditionally enable malicious behavior in other contexts.

The code emits deprecation warnings via process.emitWarning, which is not malicious but could be used to spam output.

The code uses require('arg') to load an external dependency. While 'arg' is a legitimate argument parsing library, this introduces a supply chain risk if the dependency is compromised.

The code reads process.env.NODE_OPTIONS and process.env.NODE_PENDING_DEPRECATION, which is expected for a Node.js options parser but could be leveraged to influence runtime behavior if an attacker controls these environment variables.

The code spawns child processes via callInChild for ESM support. This is a documented feature of ts-node and not a backdoor or reverse shell.

The code uses require() and Module.runMain() for normal CLI operation, which is expected for a Node.js runtime tool like ts-node; no malicious eval or obfuscated payloads are present.

The code reads a base64-encoded argument from process.argv[2] and decompresses it via decompress(). While this is a legitimate IPC mechanism used by ts-node to pass serialized state to child processes, encoded/decompressed payloads are commonly used in malware to hide intent and bypass static scanning. In this context the decoded data is used to reconstruct CLI state rather than execute hidden logic, but the pattern warrants attention.

The code rewrites process.argv[2] with a re-compressed payload when running as CLI, then proceeds to bootstrap via bin_1.bootstrap(state). This re-injects serialized state into subsequent child process invocations. If an attacker could control the initial payload (e.g., by influencing argv), the decompressed state would be trusted and used directly. No validation of the decompressed payload's schema or origin is performed.

The code directly accesses and modifies the private _process._events.warning array/object instead of using the public API (process.on, process.removeListener). This is fragile, unsupported, and can break other listeners. It is not inherently malicious, but it is a code smell and could be used to silently suppress warnings that might alert a user to malicious behavior.

The code uses require('module') to import Node's built-in module system at runtime. While this is a legitimate use for accessing the loader internals, it indicates dynamic module loading behavior that should be considered within a broader supply-chain risk assessment.

The file requires '../' (a relative parent module) and invokes its .register() method at the top level. This executes code immediately upon import and can load arbitrary transpilation plugins depending on the parent module's implementation. While this is the standard pattern for ts-node/register/transpile-only.js, it demonstrates runtime code execution and dynamic module resolution that could be abused if the parent package is compromised or resolved unexpectedly.

The require('../') call and subsequent .register() invocation run automatically when this file is imported, with no guard. This is a common entrypoint pattern for register hooks, but it means simply requiring this module triggers behavior (transpiler registration) without explicit user action.

The file executes code at import time by calling require('../').register(...). While this pattern is typical for library registration hooks, it does invoke the package's register function immediately upon loading, which could execute arbitrary behavior depending on the implementation of the required module.

The use of require('../') resolves a relative parent module dynamically at runtime. This is standard Node.js behavior, but the parent module's register implementation is not shown and could contain further logic. No obfuscation, external network calls, credential harvesting, or shell execution is present in this specific file.