Security Issue: Sandbox Escape and Arbitrary Code Execution due to usage of "vm"

[Fidget-Grep]

Hello! Hope your day is going well.

I wanted to reach out regarding a serious security issue I've identified in the usage of this library (module-from-string) as a library. Namely, any input sent to any of the exported functions (requireFromString, importFromString and importFromStringSync) is executed in a non-isolated environment, which can be easily escaped to perform malicious actions on the process running this library. Consider the following example:

import { requireFromString } from 'module-from-string'

console.log(requireFromString(
    'module.exports = process.cwd()'
))
// ReferenceError: process is not defined

When trying to execute the code process.cwd(), an error is thrown, obviously, because "process" is not defined within the context of the vm. But if we perform a sandbox escape:

import { requireFromString } from 'module-from-string'

console.log(requireFromString(
    'module.exports = this.constructor.constructor("return process.cwd()")()'
))
// /home/user/path/to/folder

It prints out the current working directory of the process running this code. This method can also be used to expose sensitive environment variables through process.env, crash the process, or even run arbitrary JavaScript code as the process itself. (luckily, this last case is less likely due to the deprecation of process.mainModule in Node.js, but it is still possible).

Ultimately I understand that some projects are not built with security in mind, but I found no official warning or documentation to suggest that module-from-string should not be used in sensitive environments, nor should its functions be run on untrusted inputs. At the very least, I would HIGHLY suggest some kind of advisory or warning outlining the danger of this package to deter anyone from using it in an unsafe way. And given that this package is used by thousands of repositories, I'm concerned that at least a few of them will be susceptible to this vulnerability.

Unfortunately I don't know how much I can help in the remediation of this vulnerability. Given that the vm module should never be used to run untrusted code, I'd like to suggest an alternative, such as vm2 or isolated-vm. However, these both have downsides. vm2 has its own security problems as well, and is not a secure alternative to vm. isolated-vm on the other hand is secure, but has much more limited features; most notably that you cannot pass modules, functions, libraries etc. into the isolated sandbox, which appears to be a prominent feature of your tool.

Please let me know if there is any way I can help in the mitigation or remediation of this vulnerability. I understand it may be difficult to properly secure these functions, but I'm concerned due to the sheer volume of users that may be affected.