GHSA-r273-hxvj-fxhp

### Summary

NodeVM exposes the host `util` module to the sandbox through an unfiltered shallow copy (`Object.assign({}, util)`). On Node.js >= 22.9 this hands sandboxed code `util.getCallSites()`, a programmatic stack-introspection API that returns the host process's full call stack — absolute file paths, function names, and line numbers — including vm2 bridge internals and the embedding application's entrypoint. This bypasses the host-frame redaction established in GHSA-v27g-jcqj-v8rw, which only covers the `Error.prepareStackTrace` channel.

### Details

- Root cause — `defaultBuiltinLoaderUtil` copies every static member of the host `util` module and wraps the copy in `vm.readonly()` without filtering any member, so newly added Node APIs land in the sandbox automatically: https://github.com/patriksimek/vm2/blob/7a1f5100b96f48d34e0fe104ab37c0acc5944f92/lib/builtin.js#L25-L38 - Second equivalent channel — the deprecated `sys` builtin (an alias of host `util`) goes through the generic builtin loader `vm.readonly(hostRequire(key))`, which also carries `getCallSites`: https://github.com/patriksimek/vm2/blob/7a1f5100b96f48d34e0fe104ab37c0acc5944f92/lib/builtin.js#L230 - Bypassed protection — GHSA-v27g's redaction (`isHostFrameFileName` + `applyCallSiteGetters`) rewrites host-frame metadata getters to `null` only when the *sandbox realm* formats an error stack: https://github.com/patriksimek/vm2/blob/7a1f5100b96f48d34e0fe104ab37c0acc5944f92/lib/setup-sandbox.js#L818-L870

`util.getCallSites()` produces its data host-side and never passes through that formatter, so frames such as `lib/bridge.js @apply` (the bridge apply trap), `lib/nodevm.js @run`, the embedder's own entry file, and `node:internal/*` frames reach the sandbox verbatim as data properties (`scriptName`, `functionName`, `lineNumber`, `columnNumber`, `scriptId`). A repository-wide grep (source, docs/ATTACKS.md, CHANGELOG, tests) shows no occurrence of `getCallSites`; the member was never considered.

### PoC

Prerequisites: Node.js >= 22.9 (verified on v22.23.1); run `npm ci --no-audit --no-fund` at the repository root.

One-line reproducer (prints `/workspace/repo/lib/bridge.js`, i.e. a vm2-internal host path):

node -e "const {NodeVM}=require('/workspace/repo'); console.log(new NodeVM({require:{builtin:['util']}}).run(\"module.exports = require('util').getCallSites(4)[0].scriptName\"))"

Observed frames inside the sandbox, with both `require: { builtin: ['util'] }` and `require: { builtin: ['*'] }`:

/workspace/repo/lib/bridge.js @apply:1664 vm.js @:5 /workspace/repo/lib/bridge.js @apply:1664 /workspace/repo/lib/nodevm.js @run:563 /workspace/out/<embedder entrypoint>.js @main:29 node:internal/modules/cjs/loader @:1781 node:internal/modules/cjs/loader @:1913 ... (8 node:internal/* frames in total)

### Impact

Information disclosure. Any NodeVM configuration that allows the `util` (or `sys`) builtin — including the wildcard `builtin: ['*']`, both typical configurations from the README — lets untrusted sandboxed code programmatically read the host call stack: the vm2 installation path, the embedding application's file layout and entrypoint, and internal function names and line numbers. This is the same information category redacted by GHSA-v27g-jcqj-v8rw (Defense Invariant #5 in docs/ATTACKS.md) and breaks defense-in-depth assumptions of embedders that rely on host frames being invisible to the sandbox. The API returns only strings/numbers (no host object references); no escalation to code execution was identified.

Suggested fix: filter members in `defaultBuiltinLoaderUtil` (allowlist, or at minimum drop `getCallSites`), apply the same treatment to the generic loader path used by `sys`, and extend the GHSA-v27g regression tests to cover programmatic stack-introspection APIs.