Summary
Togoder Security scanned the npm package @tailwindcss/oxide-wasm32-wasi@4.3.3 on Oct 6, 2026. An AI review of 4 source files produced 1 high, 8 medium, 6 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 15
Excessive filesystem preopens
NPS-5F776BEC7CD9
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.
WASI filesystem preopen of root
NPS-1F0E2B4F1A77
WASI configuration preopens '/' to '/', granting the virtualized WASM/WASI module access to the entire root of its memfs volume. Combined with the FS proxy worker, filesystem operations could extend beyond the package scope if the sandbox is misconfigured.
Dynamic network fetch at import time
NPS-5AFE33496CD5
The module fetches a remote WASM binary via fetch(__wasmUrl) at top-level. While __wasmUrl points to a local package-relative file, any compromise of the hosting resource path or supply-chain redirection could allow arbitrary code execution via the loaded WASM module.
Environment variable exposure
NPS-C0943779D5CE
All process environment variables are passed to the WASI instance and spawned workers (env: process.env), potentially exposing sensitive environment credentials (API keys, tokens, secrets) to the WebAssembly module and worker threads.
Broad filesystem preopen
NPS-B7206E142978
The WASI instance preopens the filesystem root ([__rootDir]: __rootDir), granting the WebAssembly module access to the entire filesystem rather than limiting it to the package directory. This exceeds the principle of least privilege and could allow the WASM module to read/write arbitrary files if exploited.
Broad filesystem preopens
NPS-A0822711E878
WASI is configured with preopens mapping the entire host root '/' to '/' inside the WASI sandbox. This grants the WebAssembly module unrestricted access to the entire host filesystem from within the WASI environment, which could allow reading or writing files far outside the package scope, including credentials and system files.
Dynamic code execution via eval
NPS-FDA3DE7A4473
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-E7A843A7FCA2
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-3354AEB490E7
All process environment variables (process.env) are passed to the WASI instance, potentially leaking sensitive secrets (API keys, tokens) into the sandboxed WASM module.
Web Worker spawn
NPS-5093B2025B68
Creates a Web Worker from './wasi-worker-browser.mjs'. This is expected for WASI/N-API runtimes but executes separate module code in a worker context, which is a code-execution surface that should be reviewed.
Dynamic WASM module instantiation with import rewriting
NPS-33F0901CD5F4
overwriteImports mutates the import object for the WASM module (env/napi/emnapi/memory). This is typical for N-API/WASI shims, but it constitutes dynamic module loading that should be verified against the pinned package version.
Dynamic file resolution and loading
NPS-6219070CD57E
The module uses require.resolve to dynamically locate a WASM file from another package (@tailwindcss/oxide-wasm32-wasi) and reads it via readFileSync, then instantiates it as WebAssembly. The code also auto-selects a debug WASM file if present, which could be replaced by an attacker with filesystem write access.
Worker thread spawning
NPS-4187FA8E6C65
Spawns Worker threads executing wasi-worker.mjs with full environment access. While this is standard for NAPI-RS WASI runtimes, the combination with filesystem root preopen and env exposure increases attack surface.
Node.js internals manipulation
NPS-25ECAF5C29D8
The code uses Object.getOwnPropertySymbols to locate internal Node.js symbols (kPublicPort, kHandle) and overrides their ref methods to prevent workers from keeping the event loop alive. This is a hack into undocumented Node.js internals, which is fragile and bypasses worker lifecycle management.
Top-level side effects / message handler exposure
NPS-7D86EE82A61B
The module sets globalThis.onmessage at import time to route messages into the WASI MessageHandler. Depending on the hosting environment (e.g., workers), incoming messages could trigger arbitrary WASM module instantiation and execution, expanding the attack surface of the package.
Files reviewed
| File | Verdict | What the reviewer saw |
|---|---|---|
| tailwindcss-oxide.wasi-browser.js | medium | The file is a legitimate N-API/WASI browser runtime shim for tailwindcss-oxide, with expected dynamic WASM loading, worker spawning, and broad WASI preopens; no exfiltration, credential harvesting, obfuscation, or shell execution was observed, but the dynamic WASM fetch and root preopen warrant supply-chain review. |
| tailwindcss-oxide.wasi.cjs | medium | Auto-generated NAPI-RS WASI loader for tailwindcss-oxide exhibits broad filesystem and environment access with Node.js internal hacking, but no clear malicious pattern such as exfiltration, credential harvesting, or backdoors was detected. |
| wasi-worker-browser.mjs | medium | The code configures a WASI environment with root filesystem preopens and exposes a global message handler, which is unusual and may grant overly broad filesystem access, but no explicit exfiltration, credential harvesting, obfuscation, or shell execution was found. |
| 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. |
Frequently asked questions
Is @tailwindcss/oxide-wasm32-wasi safe to use?
No confirmed malware was found in @tailwindcss/oxide-wasm32-wasi@4.3.3, but the review flagged 1 high, 8 medium, 6 low severity findings for risky patterns worth checking before you rely on it.
Does @tailwindcss/oxide-wasm32-wasi contain malware?
No malware was identified in @tailwindcss/oxide-wasm32-wasi@4.3.3 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 @tailwindcss/oxide-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 @tailwindcss/oxide-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 @tailwindcss/oxide-wasm32-wasi@4.3.3, cost nothing.