@tybys/wasm-util@0.10.4 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.

In the browser fallback, fd_read for fd 0 uses window.prompt() to read stdin. This is legitimate for browser WASI usage but means the library interacts with the page context. It only runs when fd_read(0, ...) is called at runtime, not at import time.

proc_exit calls process.exit(rval) when running under Node. This is expected WASI semantics (proc_exit is supposed to terminate), not a backdoor, but it does terminate the host process on guest request, which callers should be aware of.

The module wires WASI syscalls to Node's fs/promises and supports asyncify or JSPI wrapping. This is the intended design of a WASI preview1 implementation. No obfuscated code, eval, child_process, or network access was observed.

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.

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.