Summary
Togoder Security scanned the npm package @esbuild/android-x64@0.24.2 on Oct 4, 2026. An AI review of 2 source files produced 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 4
Expected WebAssembly Runtime Shim
NPS-9FFE944BBE7D
This is the standard, unmodified wasm_exec.js runtime shim from the Go project. It contains no obfuscation, no dynamic eval, no network calls, and no filesystem or process manipulation beyond the intended Go WASM ABI stubs. All 'fs' and 'process' polyfills either buffer console output or return ENOSYS; no external data transmission, credential harvesting, or command execution is present.
Global scope modification
NPS-892EBEAC37FD
The script monkey-patches globalThis with Node.js core modules (require, fs, TextEncoder, TextDecoder, performance, crypto). This is standard for the Go WebAssembly shim to expose Node APIs to WASM, but it does modify the global environment.
Environment variable access
NPS-1816AE81A213
The script reads and passes the entire process environment (process.env) into the Go WebAssembly runtime. While this is standard for Go's wasm_exec_node.js launcher and necessary to preserve environment variables for the WASM program, it means any secrets present in the environment are accessible to whatever WASM binary is executed. In a legitimate Go toolchain context this is expected behavior, but it constitutes broad environment variable exposure.
Dynamic code execution via WebAssembly
NPS-D5C0DDF6E328
WebAssembly.instantiate() loads and executes a WASM binary passed as a command-line argument (process.argv[2]). This is the intended purpose of the Go wasm_exec_node.js shim, but it does execute arbitrary WASM code provided at runtime, which could be a vector if arguments are attacker-controlled.
Files reviewed
| File | Verdict | What the reviewer saw |
|---|---|---|
| wasm_exec_node.js | medium | The file is the legitimate Go project wasm_exec_node.js launcher; it accesses process.env and executes a WASM binary, but no data exfiltration, credential harvesting, obfuscation, backdoors, or shell spawning is present. |
| wasm_exec.js | safe | File is the official Go wasm_exec.js runtime shim with no malicious patterns detected; only benign polyfills and WASM ABI glue code are present. |
Affected version ranges
None of the 2 scanned versions of @esbuild/android-x64 are flagged high or critical. The latest scanned version, 0.28.2, is clean. Only versions we have scanned are listed; unscanned versions between them are not covered.
| Versions | Verdict | Count | Range | Top findings |
|---|---|---|---|---|
| 0.28.2 | No issues | 1 | 0.28.2 | |
| 0.25.8 – 0.28.1 | Not scanned | 4 | >=0.25.8 <=0.28.1 | |
| 0.24.2 | Needs review | 1 | 0.24.2 |
Full list, including published versions not scanned yet: version ranges API.
Scanned versions of @esbuild/android-x64
Frequently asked questions
Is @esbuild/android-x64 safe to use?
No confirmed malware was found in @esbuild/android-x64@0.24.2, but the review flagged 4 low severity findings for risky patterns worth checking before you rely on it.
Does @esbuild/android-x64 contain malware?
No malware was identified in @esbuild/android-x64@0.24.2 when Togoder Security scanned it on Oct 4, 2026. A new version can still introduce malicious code, so scan the exact versions in your lockfile.
How was @esbuild/android-x64 checked?
Togoder Security downloaded the published npm package and had an AI model read its 2 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 @esbuild/android-x64 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 @esbuild/android-x64@0.24.2, cost nothing.