Skip to content

2026-02-06 — @enclave-vm/core Node.js vm sandbox escape via infinite recursion (CVE-2026-25533)

GitHub published an advisory for sandbox escape in @enclave-vm/core (formerly enclave-vm).

Why this matters (durable guidance)

This is another concrete example of a long-running lesson:

  • Node’s vm is not a security boundary.
  • “AST sanitization” + “blocked constructors” + error-object hardening are brittle when the underlying runtime can leak host references.

If you are executing attacker-controlled JavaScript (or “prompt-generated code”) in-process, assume sandbox escapes are possible and design accordingly.

Practical guidance

If you use @enclave-vm/core

  • Upgrade to 2.10.1+.
  • Treat any compromise of the enclave as compromise of the host process:
  • secrets in memory
  • filesystem access available to the process
  • network access available to the process

If you run untrusted JS generally

Prefer process / container / VM isolation over in-process sandboxes:

  • Run untrusted code in a separate OS process with:
  • a dedicated, unprivileged user
  • a read-only filesystem (where possible)
  • strict network egress controls
  • seccomp/AppArmor/SELinux profiles
  • Treat IPC boundaries as part of the threat model.

See also: Best practice: Agentic Browsers — Isolation + Threat Model

Detection / hunting ideas

  • Look for unexpected access to process bindings / spawn primitives (e.g., process.binding('spawn_sync')) from sandboxed execution contexts.
  • Alert on sandboxed workers attempting to read sensitive local paths (e.g., /etc/passwd, app configs, cloud credentials).

References