vm2 RCE (AIKIDO-2026-10689) spotted

vm2 is a Node.js sandbox library. People use it when they want to run untrusted JavaScript without handing that code the keys to the server. The problem is that vm2 lives inside the same process as the app it is trying to protect — and that design keeps springing leaks. This week, GitHub reviewed a fresh critical breakout bug, CVE-2026-24118, published May 1 and updated May 4, with a patch in vm2 3.11.0. (github.com) ### What actually broke? The new bug is a sandbox escape through JavaScript’s `__lookupGetter__` behavior. In plain English, code running inside the sandbox can abuse a boundary-crossing edge case, reach host-side objects, recover the host `Function` constructor, and then run arbitrary code on the underlying system. GitHub’s advisory includes a proof of concept that ends by executing a shell command on the host. (github.com) ### Which versions are exposed? GitHub marks vm2 versions up to and including 3.10.4 as affected, and 3.11.0 as the patched version for this specific flaw. npm now shows vm2 3.11.2 as the latest release, published May 5, 2026, so maintainers are still shipping follow-up hardening right now. (github.com)ymes with the earlier ones. In January, vm2 fixed CVE-2026-22709, another critical sandbox escape tied to Promise callback sanitization, with 3.10.2 as the fix. Then more fixes landed in 3.10.3, 3.10.4, and 3.10.5 for additional escape paths. So the story here is not one bad patch. It is that (github.com)ecture. (nvd.nist.gov) ### Why does vm2 keep having this problem? Because vm2 is trying to do a very hard thing in a very hostile language. Its own npm page now says the project runs untrusted JavaScript in the same Node.js process through a dense web of Proxies, and openly warns that new bypasses will likely keep being discovered. That is the core issue. This is less like (nvd.nist.gov)o many side doors. (npmjs.com) ### Didn’t vm2 come back from the dead? It did. The maintainer announced a “resurrection” in late 2025 and released 3.10.0 with the goal of patching known issues and actively maintaining the project again. That matters because the old story around vm2 was basically “use at your own risk.” The new story is better — active maintenance, frequent patches, clearer warnings(npmjs.com)as strong isolation. (github.com) ### So who should care? Anyone letting user-supplied or third-party JavaScript run through vm2 should care immediately. Plugin systems, workflow tools, low-code platforms, AI agent sandboxes, online code runners, and internal automation that treats vm2 as a trust boundary are the obvious risk zones. If an attacker can get code into the sandbox, this class(github.com)and execution.” That is the whole game. (github.com) ### What should teams do now? First, find every place vm2 is in use — direct dependency or buried transitively. Then patch past the affected range, but do not stop there. vm2’s own guidance is blunt: keep it updated, and do not rely on it as your only line of defense. Separate network access, lock down filesystem and process privileges, and move truly(github.com)ses, containers, or V8 isolates where possible. (github.com) ### Bottom line? The news is not just “vm2 had another CVE.” The bigger point is that vm2’s maintainers and the advisories are now saying the quiet part out loud — in-process sandboxing in JavaScript is a cat-and-mouse game. If vm2 is protecting something important in your stack, treat this week’s bug as a prompt to rethink the boundary, not just bump the package. (npmjs.com)