@emnapi/runtime@1.10.0 security report

Uses new Function() and new Function('return this')() to obtain a global object reference. This is a common, well-established feature-detection pattern for cross-realm global access, not an obfuscated or injected payload. No user-controlled input is passed into Function.

Conditionally requires Node built-in modules ('worker_threads', 'buffer') via a wrapper around require/__non_webpack_require__. Only fixed literal module names are loaded, no computed or externally supplied module paths, so this is not a dynamic import abuse vector.

Reads process.execArgv to check for the --force-node-api-uncaught-exceptions-policy flag, and checks process._fatalException. This is used for Node-API compatibility behavior, not for harvesting environment variables or credentials.

Constructs a reference to the global object using multiple techniques including Function('return this')() and globalThis, global, window, self. This is standard for cross-environment libraries but can facilitate sandbox escape in restricted execution contexts.

Uses new Function('return this')() to obtain the global object. This is a form of dynamic code execution via the Function constructor, which can be a security concern in environments with strict CSP or when used to bypass restrictions. It is commonly used in legitimate polyfills but is still flagged by security scanners.

Contains runtime fallback logic to access __non_webpack_require__ and require, then dynamically loads 'worker_threads', 'buffer' modules. Conditional dynamic requires based on runtime environment can be abused, though here they are used for polyfilling Node.js APIs. This pattern is typical of Node-API bindings but represents dynamic module resolution with external influence.

The library registers FinalizationRegistry callbacks and invokes webassembly/FFI function pointers (_makeDynCall_vppp) during garbage collection finalization. If untrusted native modules are loaded, finalizers could execute arbitrary native code pointers. This is an inherent risk of Node-API/emnapi bindings, not necessarily malicious.

The code uses new Function() in two places: one for feature detection (supportNewFunction) and another for obtaining the global object (new Function('return this')()). While used in a common polyfill pattern, new Function is a form of dynamic code evaluation that can be exploited if the input is attacker-controlled. Here the input is static, but the presence of such constructs warrants caution.

The code conditionally requires 'worker_threads', 'buffer', and other Node.js built-in modules via a dynamically resolved _require variable. While this is standard for cross-environment compatibility, it demonstrates dynamic module loading based on runtime detection. This is not malicious per se but could be abused if the module resolution path were influenced by external input.

The NodeEnv.prototype.triggerFatalException method can call process.exit(1) on uncaught exceptions when not handled by the runtime. This is standard behavior for Node-API modules but represents a mechanism that could be abused to cause denial of service if an attacker can trigger an uncaught exception in a finalizer or callback.

The Context class includes methods to enable/disable calling into JavaScript and to destroy the context, which stops execution. This is expected for emnapi's functionality but could be misused if an attacker gains control over the module's environment.

The code conditionally accesses require (or __non_webpack_require__) to load worker_threads and buffer modules based on environment checks. This is not inherently malicious, but dynamic module loading with environment-dependent fallbacks can be a vector for dependency confusion or unexpected module resolution. The loaded modules (worker_threads, buffer) are standard Node.js core modules and the usage appears benign.

The code inspects globals such as process, __webpack_public_path__, global, window, self, and globalThis to adapt to different runtimes. While this is typical for cross-platform libraries, such introspection could theoretically be used to conditionally execute different code paths. No malicious behavior was observed.

The code uses new Function to detect globalThis fallback and to test configurability of Function.prototype.name. While common in polyfills, new Function is a potential vector for code execution if input is ever passed to it. Here, no external input controls the Function constructor arguments, so risk is limited.

The code dynamically resolves require/__non_webpack_require__ to load 'worker_threads', 'buffer', and potentially fallbacks. This is standard for Node.js compatibility layers (emnapi) but allows resolution of modules based on environment. No credential or env var harvesting observed.

The code can call process._fatalException and process.exit(1) on uncaught exceptions in native callbacks. This is expected behavior for a Node-API implementation but could terminate the host process. Not malicious, but noteworthy for security review.

The code uses WeakRef/FinalizationRegistry for reference tracking (standard for Node-API). No data exfiltration or persistence observed.