@tybys/wasm-util@0.10.2 security report

The code checks process.platform === 'win32' to route path resolution to a Windows-specific implementation. This is benign platform detection necessary for correct path handling and does not involve any suspicious activity.

The code reads the process.env object to look up the per-drive current working directory (=X: environment variable convention) on Windows. This is standard behavior used by Node.js's built-in path.win32.resolve to support Windows drive-specific working directories, and the values read are only used locally for path resolution, not exfiltrated.

This is the core function of a WASI implementation: it provides file system access to WebAssembly guests. By design, it manipulates files and directories via Node's fs module. While expected for this library, any vulnerability in path resolution or rights checking (see above) would allow arbitrary file system manipulation. The code does implement a rights-based capability system, which is a positive security control.

_toWinOpenFlags translates Linux flag bits to Windows libuv flags, but starts with let r = f & 3; which only preserves the lowest two bits (access mode). All other flags not explicitly handled (e.g., O_NONBLOCK, O_SYNC, O_DIRECTORY) are silently dropped on Windows. While this is primarily a correctness issue, it could lead to unexpected permission bypasses (e.g., O_DIRECTORY not being enforced at the OS level on Windows).

The code conditionally loads worker_threads and defines a postMessage implementation that sends data to parentPort. This is expected behavior for a WASI utility library but could be abused for data exfiltration if the data originates from sensitive sources.

Reads process.env for per-drive cwd lookups using the '=X:' convention. This is legitimate Windows path resolution behavior for determining current working directory per drive, not credential harvesting.

environ_get and environ_sizes_get expose all process.env values (env array passed into constructor) to the WASM guest. If the host passes full process.env, secrets such as tokens, API keys, and AWS credentials could be leaked into the WASI sandbox. This is by design in WASI but a misconfiguration risk.

NODE_DEBUG_NATIVE env var is read and, if it includes 'wasi', arguments to syscalls are logged via console.debug. Not malicious, but reading process.env at module scope could allow an attacker who controls the process environment to enable verbose logging of syscall arguments (paths, fds). Low impact.

wrapInstanceExports uses Object.defineProperty on arbitrary export names from the provided exports object. No external input is involved here, but it is a pattern worth noting for WASI module wrapping.

The code attempts to obtain a native require function via __webpack_public_path__ and __non_webpack_require__, then uses it to load the 'worker_threads' module. While the target module is hardcoded, this pattern bypasses webpack bundling and can be used to load arbitrary modules in some environments.

The module conditionally spawns or interacts with worker_threads, including reading isMainThread and using parentPort.postMessage to send data to the main thread. This is legitimate for WASI threading support but constitutes inter-thread communication that could be abused if the package is compromised.