CVE-2026-44643: Sandbox Escape and Remote Code Execution in angular-expressions

The peerigon/angular-expressions library provides a standalone implementation of AngularJS expressions for Node.js and browser environments. The component relies on a dedicated sandbox mechanism to parse and evaluate user-supplied string expressions safely. This design restricts access to global objects, preventing standard JavaScript primitives from executing within the host context.

The vulnerability identified as CVE-2026-44643 constitutes an Eval Injection flaw (CWE-95). The breakdown occurs within the expression parsing logic, specifically where property access boundaries for filters are established. Attackers exploit this boundary failure by supplying carefully structured string expressions that traverse the JavaScript prototype chain.

Successful exploitation results in immediate, unauthenticated remote code execution. Systems evaluating untrusted input through the library are highly exposed, resulting in a CVSS 4.0 score of 9.3. The impact is particularly severe in backend Node.js environments where access to the process object grants comprehensive system control.

The root cause of the vulnerability is the insufficient validation of property access during the resolution of expression filters. The parser evaluates expression strings and dynamically looks up properties to apply the required filter logic. Prior to version 1.5.2, the compiler did not consistently require hasOwnProperty validation checks on the target objects.

This lack of strict property enforcement facilitates prototype traversal. Attackers construct payloads that reference the __proto__ or constructor attributes of the objects being evaluated. The parser processes these attributes sequentially, ascending the prototype chain instead of restricting lookups to the object's own properties.

Reaching the top of the prototype chain provides the attacker with a reference to the global Function constructor. The Function constructor dynamically generates and executes JavaScript code from raw string inputs. Invoking this constructor bypasses the library's intended containment, allowing interaction with the host environment and native Node.js libraries.

In vulnerable versions, the files lib/parse.js and lib/main.js handled object property lookups directly without verifying ownership. The parser permitted expressions to navigate through the filter object and retrieve properties inherited from Object.prototype. This architectural decision left the constructor property entirely exposed during evaluation.

The remediation introduced in version 1.5.2 implements several structural hardening techniques. The primary defense is the introduction of a bounded hasOwn function replacing standard property lookups. This utility strictly calls Object.prototype.hasOwnProperty.call, preventing attackers from overriding or bypassing the check by mutating the evaluated object.

// Conceptual representation of the fix in lib/parse.js
// Before Patch
if (obj[key]) { return obj[key]; }
 
// After Patch
const hasOwn = Function.prototype.call.bind(Object.prototype.hasOwnProperty);
if (hasOwn(obj, key)) { return obj[key]; }

Additionally, the patch alters how the filter registry is instantiated. The registry is now initialized using Object.create(null). This creates a null-prototype object, effectively stripping the __proto__ and constructor properties from the root filter context. The ASTCompiler was also modified to detect and block explicit prototype traversal syntaxes.

Exploitation requires the application to pass user-controlled strings into the angular-expressions evaluation function. The attacker embeds a malicious payload within standard AngularJS filter syntax. The payload appears syntactically valid to the parser but logically forces the evaluation engine to navigate the object tree.

A functional exploit payload uses consecutive constructor calls to step outside the sandbox constraints. The following string demonstrates the bypass mechanism:

"1 | filter: 'constructor.constructor(\"return process\")().mainModule.require(\"child_process\").execSync(\"id\")()'"

When the parser processes this string, the filter lookup resolves the constructor of the filter function itself. The second constructor call accesses the global Function constructor. The attacker passes "return process" to retrieve the active Node.js process object, subsequent calls require the child_process module, and finally invoke execSync to execute arbitrary operating system commands.

The execution of arbitrary code via this vulnerability completely compromises the host application. The attacker executes instructions with the privileges of the underlying Node.js process. This level of access typically permits the extraction of sensitive environment variables, database connection strings, and application configuration files.

The CVSS v4.0 vector (CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N) reflects the critical severity of the flaw. The attack vector is strictly network-based, requires no special privileges, and functions independently of user interaction. The impact metrics for confidentiality, integrity, and availability are fully maximized.

In containerized or cloud-native environments, the compromised Node.js process can serve as a staging point for lateral movement. The attacker utilizes standard post-exploitation techniques to pivot into internal networks or cloud service metadata endpoints.

The primary remediation step is upgrading the angular-expressions dependency to version 1.5.2 or later. This patch fundamentally alters the object property lookup mechanism and removes the prototype chain from the filter registry. Applying this update neutralizes the known exploitation vectors immediately.

If immediate patching is unfeasible, administrators must apply runtime mitigations. Node.js applications should be executed with the --disable-proto=delete flag. This command-line argument globally disables __proto__ mutations across the runtime, significantly degrading the reliability of prototype-based sandbox escapes.

Developers must implement stringent input validation on any strings passed to the expression evaluator. The application layer should reject inputs containing keywords explicitly associated with traversal or code execution, such as constructor, __proto__, Function, or eval. Defense-in-depth measures, including rigorous Content Security Policies (CSP), restrict the execution scope even if an escape occurs.