GitHub Security Advisory: GHSA-hw58-p9xv-2mjh
Package: vm2 (NPM)
Severity: HIGH (CVSS 8.6)
CWE: CWE-248: Uncaught Exception
Vulnerable versions: <= 3.10.5
Patched in: 3.11.0

Summary: vm2 has a Sandbox Escape via Promise Constructor Unhandled Rejection (Process Crash DoS)

Details:
### Summary
A sandbox escape vulnerability in vm2 v3.10.5 allows any sandboxed code to crash the host Node.js process via a single Promise constructor that triggers an unhandled rejection propagating to the host. The fix for CVE-2026-22709 (v3.10.2) only sanitized the `onRejected` callback in `.then()` and `.catch()` overrides and did not address the executor-to-unhandledRejection path.

### Details
When sandboxed code creates a `Promise` whose executor sets `Error.name` to a `Symbol()` and then accesses `.stack`, V8's internal `FormatStackTrace` (C++) attempts `Symbol.toString()`, which throws a **host-realm TypeError**. Because this error originates inside the Promise executor and no `.catch()` handler is attached, it becomes an **unhandled rejection** that propagates to the host process.

- `lib/setup-sandbox.js:38` — `localPromise` wraps the native `Promise` constructor but does not wrap the executor in try-catch.
- `lib/setup-sandbox.js:165-230` — `resetPromiseSpecies` and the `.then()`/`.catch()` overrides sanitize the `onRejected` callback chains, but do not intercept unhandled rejections originating from the executor itself.

The CVE-2026-22709 patch (v3.10.2) sanitized `.then()` and `.catch()` callback chains but left the executor-to-unhandledRejection path completely open.

**Root Cause**: Promise executor errors are not caught/sanitized before they can propagate as unhandled rejections to the host process, causing an immediate process crash.

**`allowAsync: false` does not help**: This setting only blocks `async`/`await` syntax and overrides `.then()`/`.catch()` to throw. The `Promise` constructor itself is still callable. Worse, because `.catch()` is blocked, any rejection from the executor is *guaranteed* to be unhandled — making `allowAsync: false` paradoxically more dangerous than `true` for this vulnerability.

### PoC

**Library-level PoC (Node.js script — primary):**
```javascript
const { VM } = require("vm2");

// Works with ANY allowAsync setting — both true and false
const vm = new VM({ timeout: 5000, allowAsync: false });

try {
  const result = vm.run(`
    new Promise(function(r, j) {
      var e = new Error();
      e.name = Symbol();
      e.stack;
    });
  `);
  console.log("Result:", result);   // Reaches here (returns Promise object)
} catch (err) {
  console.log("Caught:", err);       // Never executed
}

console.log("After try-catch");      // Also prints normally

// But on the next microtask tick:
// [UnhandledPromiseRejection: TypeError: Cannot convert a Symbol value to a string]
// Exit code: 1
//
// try-catch cannot help — vm.run() returns synchronously,
// the rejection fires asynchronously outside any catch scope.
//
// NOTE: allowAsync: false only blocks async/await syntax and
// .then()/.catch() method calls. The Promise constructor itself
// still executes, and the unhandled rejection still propagates.
// In fact, allowAsync: false makes it WORSE — .catch() is blocked,
// so the rejection is guaranteed to