Summary
Togoder Security scanned the npm package @unrs/resolver-binding-wasm32-wasi@1.12.2 on Oct 6, 2026. An AI review of 4 source files produced 1 high, 7 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 12
Excessive filesystem preopens
NPS-3DF5870E0ACE
The WASI instance is configured with preopens mapping the root directory (__rootDir) to itself. This gives the WASM module unrestricted access to the entire filesystem, far beyond what is typically necessary, enabling potential data theft or tampering.
Environment variable access
NPS-3710ADF6A049
The code passes process.env directly to the WASI environment (env: process.env) and to worker threads (env: process.env), potentially exposing all environment variables to the WASM runtime and worker threads. This could leak sensitive environment variables if the WASM module or worker code is compromised.
Broad filesystem preopens
NPS-155BA35E917E
The WASI instance is configured with preopens mapping the filesystem root (/) to itself ([__rootDir]: __rootDir), granting the WASM module full filesystem access. This violates the principle of least privilege and could allow malicious WASM code to read or write any file on the system.
Dynamic code execution via WebAssembly
NPS-60F7BF02A52E
The module loads and instantiates WebAssembly code from a file (resolver.wasm32-wasi.wasm) that is read at runtime. While this is typical for NAPI-RS WASM bindings, the WASM binary is not verified or integrity-checked, so if the file is tampered with, arbitrary native-like code could execute with the above permissions.
Broad filesystem access
NPS-995722DFCBE4
The WASI preopens configuration maps the root directory '/' to itself, granting the WebAssembly instance access to the entire container filesystem. While the actual host filesystem access is limited by the browser environment and memfs proxy, this broad preopen could allow the WASM module to read or write files outside the package scope if the runtime environment permits it.
Dynamic code execution via eval
NPS-697819FBCACD
The importScripts function uses (0, eval)(...) to evaluate arbitrary code read from a file path. If a malicious actor can influence the filename passed to importScripts, this could lead to arbitrary code execution in the worker context.
Dynamic module loading with computed input
NPS-80D48E562583
The importScripts function reads a file from an arbitrary path and evals it. The path is provided by the caller (e.g., via postMessage from the parent thread). This could be exploited if the parent thread or another attacker controls the message payload.
Environment variable exposure
NPS-93A3FC708B66
All process environment variables (process.env) are passed to the WASI instance, potentially leaking sensitive secrets (API keys, tokens) into the sandboxed WASM module.
Worker thread with inherited environment
NPS-A855C8B1751B
Worker threads are spawned with env: process.env, giving them access to all environment variables. Combined with the broad filesystem preopens, this increases the attack surface if the worker code is malicious.
Node.js internal handle manipulation
NPS-3E7B4E9B29FD
The code uses Object.getOwnPropertySymbols to find internal worker symbols (kPublicPort, kHandle) and overwrites their ref methods to prevent the worker from keeping the event loop alive. This is a hack that relies on undocumented Node.js internals and could be used to hide active worker threads, though in this context it appears to be a workaround for Rust thread management.
Dynamic code loading
NPS-683F7481CE90
The code instantiates a WebAssembly module from a message-provided wasmModule. If an attacker can control the message source, they could supply a malicious WASM binary for execution. However, in typical usage this is expected behavior for a WASM worker.
Unvalidated message handling
NPS-C53D6E1C7C87
The global onmessage handler directly passes incoming postMessage events to the MessageHandler without origin validation. This could enable cross-origin or malicious messages to trigger WASM module loading or interaction if the worker is embedded in an untrusted context.
Files reviewed
| File | Verdict | What the reviewer saw |
|---|---|---|
| resolver.wasi.cjs | medium | The file appears to be a legitimate NAPI-RS generated WASI loader, but it grants broad filesystem access and exposes all environment variables to WASM and worker threads, which could be risky if the WASM binary is compromised. |
| wasi-worker-browser.mjs | medium | This is a standard WASI worker for running WebAssembly modules with N-API bindings; it uses broad filesystem preopens and unvalidated message handling but contains no clear malicious exfiltration, credential theft, or obfuscation patterns. |
| wasi-worker.mjs | medium | The WASI worker exposes dangerous eval-based script loading and grants full filesystem and environment access to a WASM module, creating potential security risks if misused or if message inputs are untrusted. |
| resolver.wasi-browser.js | safe | No malicious patterns detected; the file is a standard WebAssembly/NAPI browser runtime loader for a resolver module. |
Frequently asked questions
Is @unrs/resolver-binding-wasm32-wasi safe to use?
No confirmed malware was found in @unrs/resolver-binding-wasm32-wasi@1.12.2, but the review flagged 1 high, 7 medium, 4 low severity findings for risky patterns worth checking before you rely on it.
Does @unrs/resolver-binding-wasm32-wasi contain malware?
No malware was identified in @unrs/resolver-binding-wasm32-wasi@1.12.2 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 @unrs/resolver-binding-wasm32-wasi checked?
Togoder Security downloaded the published npm package and had an AI model read its 4 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 @unrs/resolver-binding-wasm32-wasi 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 @unrs/resolver-binding-wasm32-wasi@1.12.2, cost nothing.