Due to its comprehensive control over the sandbox’s console output and the ability to restrict access to specific built-in modules or securely call methods and communicate data between sandboxes, it is one of the most liked testing environments used by millions of engineers.
Security researchers discovered a flaw in the vm2 sandbox when executing untrusted code. The sandbox configuration does not properly handle exceptions, leaving the system vulnerable to potential exploitation. This flaw allows an attacker to bypass the sandbox protections and gain access to the hypervisor host or the host executing the sandbox. A vulnerability management tool handles defects like CVE-2022-36067.
We were surprised when we discovered this vulnerability, as the vm2 sandbox module is extremely popular, and sandboxes, by their definition, should be safe. At the same time, we also felt glad that we found it, as we could then help secure it and give back to the community. After all, we are not only security Affected Product’s and enthusiasts but also developers who use open source componentsDean Agron, CEO of Oxeye.
On August 28, the vm2 team released version 3.9.11, which addressed the SandBreak vulnerability. However, they have kept the technical details about the flaw hidden so far.
The root cause of the CVE-2022-36067 vulnerability, which Oxeye’s researchers have named SandBreak, resides in the way vm2 maintainers implemented a Node.js feature that allows them to customize the call stack of errors in the software testing framework.
Affected Products by CVE-2022-36067
A threat actor may bypass sandbox protections to obtain remote code execution privileges on the host running the sandbox.
vm2 3.9.11 fixes the vulnerability for sandbox escape.