Hey @SuperOP535 -- original reporter here :) I tried reproducing the issue with:
~ ᐅ cd /tmp
/tmp ᐅ npm i safe-eval
npm WARN saveError ENOENT: no such file or directory, open '/tmp/package.json'
npm WARN enoent ENOENT: no such file or directory, open '/tmp/package.json'
npm WARN tmp No description
npm WARN tmp No repository field.
npm WARN tmp No README data
npm WARN tmp No license field.
added 1 package from 1 contributor and audited 2 packages in 1.854s
found 1 critical severity vulnerability
run `npm audit fix` to fix them, or `npm audit` for details
/tmp ᐅ node
> safeEval = require('safe-eval')
> safeEval("this.constructor.constructor('return process')().exit()")
TypeError: this.constructor.constructor is not a function
at Script.runInContext (vm.js:102:20)
at Script.runInNewContext (vm.js:108:17)
at Object.runInNewContext (vm.js:291:38)
at safeEval (/tmp/node_modules/safe-eval/index.js:24:6)
at Script.runInThisContext (vm.js:91:20)
at REPLServer.defaultEval (repl.js:317:29)
at bound (domain.js:396:14)
at REPLServer.runBound [as eval] (domain.js:409:12)
and it looks like safe-eval 0.4 fixes it. Not sure how the NPM advisories work, as it should probably be closed.
Unfortunately the sanitisation in 7051474 is not sufficient to close the hole. I have sent a proof-of-concept to @hacksparrow by email.
The new exploit (like the one reported by @odino) is fragile, and there are many trivial ways to break it, but in general any access by the eval-ed code to any object from the caller's realm (e.g., if any object is passed in via context) will allow escaping the sandbox.
I would advise using vm2 instead. (Please note that I have not audited the code of vm2, so can make no representations about its correctness—but at least its author appears to fully understand the issues.)