CVE-2026-92954: vm2 3.10.0 through 3.11.7 Denial of Service via Host Promise

Published Sep 17, 2026
·
Updated

Summary

vm2 current head (v3.11.5, commit 7a1f5100b96f48d34e0fe104ab37c0acc5944f92) can still be used to terminate the host Node.js process when sandbox code calls a host-realm function that returns a rejected host Promise and then ignores the returned value.

This is an incomplete-fix variant of the GHSA-hw58-p9xv-2mjh unhandled rejection hardening. The localPromise constructor now catches and consumes sandbox-created unhandled rejections, but host Promises returned across the bridge are not marked handled at the bridge boundary. If the sandbox does not attach .catch() or .then(..., onRejected), Node's default unhandled rejection behavior terminates the host process.

Technical Details

lib/setup-sandbox.js hardens sandbox-created Promises by wrapping the executor and attaching a benign swallow tail:

js apply(globalPromisePrototypeThen, this, [undefined, localPromiseSwallow]);

That only applies to localPromise instances created inside the sandbox.

Host-returned Promises cross the membrane through the bridge apply path. The bridge wraps callbacks when sandbox code later calls .then, .catch, or .finally on a host Promise:

js bridge.setHostPromiseSanitizers(e => handleException(from(e)), from);

However, if sandbox code ignores the returned host Promise, no host-side rejection handler is attached. The original host Promise remains unhandled and Node terminates the host process under the default unhandled-rejection behavior.

NodeVM provides an in-repository example of this primitive through the special events builtin wrapper. lib/builtin.js passes host EventEmitter.once into the sandbox:

js once: EventEmitter.once,

Then lib/events.js re-exports it:

js if (host.once) module.exports.once = host.once;

Calling events.once(ee, 'message') and then emitting error on ee returns a rejected host Promise through that wrapper. If ignored by sandbox code, it terminates the host process.

Impact

An attacker who can run code in a vm2 sandbox can terminate the host Node.js process when the embedder exposes a host Promise-returning API, or when a NodeVM permits the events builtin.

For web services, queues, notebook workers, plugin hosts, and multi-tenant code execution systems, a single small request can terminate the worker process. Restart policies do not fully mitigate the issue because the payload can be replayed after each restart.

Affected Package/Versions

Confirmed affected on Node.js v25.8.0:

- v3.10.0 - v3.10.1 - v3.10.2 - v3.10.3 - v3.10.4 - v3.10.5 - v3.11.0 - v3.11.1 - v3.11.2 - v3.11.3 - v3.11.4 - v3.11.5 / current head 7a1f5100b96f48d34e0fe104ab37c0acc5944f92

The final PoV was also reproduced on current head with Node.js v16.20.2, v18.20.8, v20.20.2, v22.22.3, v24.16.0, and v25.9.0 using npx node@<major>. The local workstation default Node.js v25.8.0 also reproduces.

Configuration Required

The general VM PoV requires an embedder-exposed host function that can return a rejected host Promise:

js const vm = new VM({ sandbox: { hostReject: () => Promise.reject(new Error('host-boom')), }, });

The NodeVM variant requires events in the builtin allowlist:

js new NodeVM({ require: { external: false, builtin: ['events'] } });

events.once() is exposed by vm2's special events builtin wrapper. Node's official API documents events.once() as returning a Promise that rejects when the watched emitter emits error while waiting for another event.

Controls

- If sandbox code attaches .catch(() => {}) to the returned host Promise, the process survives. - If sandbox code creates and ignores a sandbox-native rejected Promise, the process survives on current head. This confirms the GHSA-hw58 localPromise hardening is active. - If sandbox code attaches .catch(() => {}) to the events.once() Promise, the NodeVM process survives. - If NodeVM does not allow the events builtin, the events.once() variant does not run and the process survives.

Disclosure Policy Fit

vm2's security policy asks reporters not to open public issues and to submit This report is intended for that private route and includes the requested reproduction steps, affected versions, environment/configuration details, and impact. The affected range is within the supported 3.x line.

Local Proof of Concept

Run from the oss-zero-day-harness directory:

fish node submission-bundle/vm2-pov-test-host-promise-return-unhandled-rejection-dos/pov-host-promise-return-unhandled-rejection-dos.js

The crash-safe PoV executes each case in a child process. A vulnerable result has status: 1 for the positive cases and status: 0 for controls.

Minimal VM positive case:

js const { VM } = require('vm2');

const vm = new VM({ sandbox: { hostReject: () => Promise.reject(new Error('host-boom')), }, });

vm.run('hostReject(); 1'); setTimeout(() => console.log('survived'), 150);

Observed on current head:

text Error: host-boom at hostReject (...)

The process exits before printing survived.

Minimal NodeVM builtin variant:

js const { NodeVM } = require('vm2');

const vm = new NodeVM({ require: { external: false, builtin: ['events'] }, });

vm.run( const events = require('events'); const ee = new events.EventEmitter(); events.once(ee, 'message'); ee.emit('error', new Error('event-boom')); module.exports = 'returned'; , 'events-pov.js');

setTimeout(() => console.log('survived'), 150);

Observed on current head:

text node:internal/process/promises:332 triggerUncaughtException(err, true / fromPromise /); Error: event-boom

The process exits with status 1.

Mitigation

Applications can reduce exposure by installing a process-level unhandledRejection handler that swallows vm2-originated rejections, as the README recommends for related async rejection caveats. That is an application workaround, not a library-level fix: without such a handler, current Node's default --unhandled-rejections=throw behavior raises the rejection as an uncaught exception and exits the process.

Suggested Fix Direction

When a host function call returns a host-realm Promise across the bridge into sandbox code, attach a benign host-side rejection handler to the raw returned Promise before wrapping it for the sandbox. This should mark the original host Promise handled without changing the value returned to sandbox code or hiding the rejection from sandbox code that later attaches its own .catch() / .then(..., onRejected).

Regression tests should cover:

- VM with hostReject: () => Promise.reject(new Error(...)); calling hostReject() without .catch() must not terminate the process. - The same call with a sandbox .catch() must still deliver a sanitized rejection to the sandbox callback. - NodeVM with require.builtin: ['events']; calling events.once(ee, 'message') and then emitting error without .catch() must not terminate the process. - The same events.once() call with a sandbox .catch() must continue to deliver a sanitized rejection to the sandbox callback. - Sandbox-created rejected Promises should continue to be consumed by the existing localPromise hardening.

Why This Is Not Intended Behavior

vm2 already treats this failure mode as security-relevant. GHSA-hw58-p9xv-2mjh was assigned High severity for a sandbox-created unhandled rejection that terminated the host process, and current setup-sandbox.js explicitly states that the local Promise swallow tail exists so the host's unhandledRejection event never fires.

This report shows the same availability boundary failure still exists for host-returned Promises:

- the sandbox does not need childprocess, filesystem, network, nesting, or dangerous builtins; - the VM variant needs only a common embedder pattern: exposing an async host helper to untrusted code; - the NodeVM variant needs only the documented events builtin allowlist; - a single sandbox call terminates the whole host process serving all users.

This is distinct from the documented caveat that timeout cannot stop CPU loops. It is also distinct from the README's current async-function / await using caveat: this report does not require sandbox async syntax, async functions, disposable stacks, or V8 stack-formatting behavior. The issue is specifically that vm2's own bridge returns a host Promise to the sandbox without marking the host Promise handled, while the sandbox-created Promise path does mark rejections handled.

This is also distinct from host-Promise callback sanitizer escapes. In those chains, sandbox code attaches a callback to a host Promise and then receives or returns a mis-sanitized value. Here, no sandbox Promise callback is required at all; the original host Promise is simply left orphaned after crossing the bridge.

Other sources

vm2 is a sandbox library for running untrusted JavaScript in Node.js. In versions >= 3.10.0 and <= 3.11.7, Promises returned from the host realm into the sandbox are not marked as handled at the bridge boundary; only Promises created inside the sandbox are wrapped with a rejection-swallowing handler (lib/setup-sandbox.js), and the bridge only installs host-side rejection sanitizers when sandbox code calls .then/.catch/.finally. As a result, code running in the sandbox can invoke a host function that returns a rejected Promise (for example events.once() exposed via the NodeVM events builtin, or any embedder-provided Promise-returning API) and simply ignore the return value, leaving the host Promise unhandled so that Node.js's default unhandled-rejection behavior terminates the host process. This is an incomplete fix of GHSA-hw58-p9xv-2mjh. The issue is fixed in version 3.11.8.

— NVD

Affected Software

2 affected componentsFixes available
npm/vm2>=3.10.0<=3.11.7
npm/vm2>=3.10.0<=3.11.7
3.11.8

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade npm/vm2 to a version that resolves this vulnerability.

    Fixed in 3.11.8
  2. Upgrade

    Upgrade vm2 to a version that resolves this vulnerability.

    Fixed in 3.11.8
  3. Compensating control

    Install a process-level unhandledRejection handler that swallows vm2-originated rejections, as recommended in the README; this is an application workaround rather than a library-level fix.

Event History

Sep 17, 2026
CVE Published
via MITRE·01:46 PM
Data Sourced
via MITRE·01:46 PM
DescriptionSeverityWeakness
Data Sourced
via NVD·02:18 PM
DescriptionSeverityWeakness
Oct 5, 2026
Advisory Published
via GitHub·10:45 PM
Data Sourced
via GitHub·10:45 PM
DescriptionSeverityWeaknessAffected Software

Frequently Asked Questions

1

Who is exposed to this denial-of-service condition?

Applications using vm2 versions 3.10.0 through 3.11.7 to execute untrusted JavaScript are exposed when sandboxed code can call a host function that returns a Promise which may reject. This includes the NodeVM events builtin when events.once() is available, as well as embedder-provided Promise-returning APIs.

2

What must an attacker do to trigger the issue?

The attacker needs the ability to run code in the vm2 sandbox and invoke an exposed host-side function that returns a rejected Promise. They can then ignore that returned Promise, leaving it unhandled and allowing Node.js default unhandled-rejection behavior to terminate the host process.

3

What should be done if the affected functionality cannot be removed immediately?

Upgrade vm2 to version 3.11.8, which fixes the issue. Until then, avoid exposing Promise-returning host APIs to untrusted sandbox code, including APIs that can return rejected Promises such as events.once().

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203