Critical vm2 sandbox escape (CVSS 10.0) traced to its own README example
GitLab's Threat Research Group found a CVSS 3.1: 10.0 sandbox escape in vm2, a widely used Node.js sandbox library, in a config copied from vm2's own README. Version 3.11.7 fixes the attack, but the underlying risk remains for anyone using require.external. Update immediately and prefer containers for untrusted code.
Why it matters
vm2 runs untrusted code, such as plugin systems, coding playgrounds, CI test runners, and tools that let an AI execute its own generated code, inside a fake JavaScript environment meant to block access to the real system. Because so many applications depend on vm2 for that isolation, one escape in the library becomes an escape in every application built on it, without anything looking wrong to the developer who installed it.
What changed
GitLab's Threat Research Group, using its own AI-based tooling, found a critical (CVSS 3.1: 10.0) remote code execution flaw in vm2 versions 3.11.6 and earlier when require.external is enabled. The bug traces back to vm2's own README 'Quick Examples': setting require.external: true with root: './' looks safe, but ./node_modules, including vm2's own installed copy, sits inside that root. Because context defaults to 'host' rather than 'sandbox', requiring vm2 from inside the sandbox loads it through Node's real, unsandboxed require() instead of vm2's own loader, breaking the isolation entirely. Version 3.11.7 fixes the attack GitLab reported, but the maintainer's own description of the fix indicates the broader configuration risk is not fully resolved.
In an interview
A candidate could explain that sandbox libraries are only as safe as their default configuration, that copying an example straight from a README is not a substitute for a security review, and that GitLab's own recommendation after this bug is to avoid vm2 for isolating untrusted code and use containers or separate processes instead.
Just read this? Test yourself on what you have been reading.
Read the original → about.gitlab.com
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on nodejs — each one lists the topics its interview covers.
See open roles