The hook
vm2 is commonly used where an app needs to evaluate JavaScript while limiting what that code can reach. When a vulnerable vm2 release is present, teams should treat the sandbox boundary as a patch priority, especially for tenant scripts, plugins, workflow expressions, or AI/tool-generated code.
How it works
The repo check looks for the npm package `vm2` in dependency manifests and lockfiles. Exact lockfile versions produce high-confidence findings; broader manifest ranges are reported as version evidence when they can resolve to an affected release.
The blast radius
If a deployed app executes attacker-controlled code through an affected vm2 runtime, the sandbox may no longer be a reliable isolation layer. A repo match is dependency evidence, not proof that untrusted code reaches vm2 or that host command execution occurred.
// what fixvibe checks
What FixVibe checks
FixVibe repo scans look for high-confidence security patterns and dependency risk in source context. Reports identify the affected area and recommended fix. For check-specific questions about exact detection heuristics, active payload details, or source-code rule patterns, contact support@fixvibe.app.
Ironclad defenses
Upgrade `vm2` to 3.11.4 or newer, regenerate the active lockfile, rebuild the deployed Node.js runtime, and rerun the repo scan. If vm2 protects untrusted-code workflows, review queued inputs, tenant scripts, plugin data, logs, and credentials available to the Node.js process before treating the incident as closed.