Angular-Expressions Sandbox Escape RCE Vulnerability

A severe sandbox escape vulnerability in the angular-expressions package now gives attackers a direct path to execute arbitrary code on affected systems, heightening the risk for Node.js‑powered web applications and template‑processing services.

The flaw, tracked as CVE‑2024‑54152, resides in the way the library handles __proto__ access inside Angular‑style expressions, allowing threat actors to break out of the intended evaluation sandbox and reach the underlying JavaScript runtime.

angular-expressions is a standalone parser that evaluates AngularJS‑style expressions at runtime, commonly used in document‑templating tools such as docxtemplater and other template engines that accept user‑provided expressions.

The bug lets an attacker craft a specially formed expression that manipulates the prototype chain, escaping the “safe” sandbox context and accessing broader JavaScript objects and functions.

In practice, this means an unauthenticated, remote attacker can inject expressions into any endpoint or service that evaluates angular-expressions input, then chain that into full arbitrary code execution on the host.

A simple test case like expressions.compile("a | __proto__")({}, {}) should trigger a defined error about an undefined filter, but in vulnerable versions it instead produces a SyntaxError‑style crash, exposing instability in prototype handling.

Angular-Expressions Sandbox Escape Vulnerability

The vulnerability affects all releases of angular-expressions prior to version 1.4.3, with current guidance also recommending upgrade to at least 1.5.2 to absorb later follow‑up fixes and hardening patches.

Libraries and frameworks that depend on this package particularly server‑side template processors can become launchpads for remote code execution if they accept untrusted, user‑supplied expressions.

Because the attack is network‑based and requires no authentication or user interaction, any exposed API or microservice that evaluates Angular‑style expressions is a realistic target.

Once the sandbox is escaped, attackers can execute JavaScript commands that read, exfiltrate, or manipulate server‑side files, install backdoors, or pivot laterally within a network making this a critical‑severity risk for enterprises using the module at scale.

The root cause is insufficient validation and blocking of __proto__ access inside the expression evaluator. By injecting expressions that reference or modify prototype properties, an attacker can alter the behavior of the sandbox environment and smuggle calls into unrestricted JavaScript objects.

The vulnerability is analogous to older AngularJS sandbox‑bypass techniques, where prototype‑chain manipulation allowed toString.constructor.prototype and similar constructs to be exploited to escape restricted contexts.

In this case, the flaw is in the standalone angular-expressions module rather than the core Angular framework, so even applications that do not use AngularJS directly can be compromised if they include this package.

Patch and Mitigation

The maintainers have fixed the issue in version 1.4.3, with further hardening incorporated into 1.5.2 and above. Organizations using angular-expressions should immediately upgrade their npm dependencies to at least 1.5.2, then verify the version via node_modules/angular-expressions/package.json or equivalent package‑lock inspection.

Beyond patching, practitioners should:

Audit all code paths that accept or compile user‑supplied expressions with angular-expressions and either disable or strictly sanitize them.
Block or reject any expressions containing __proto__, prototype‑related keywords, or function‑constructor patterns until the dependency is upgraded.
If possible, disable __proto__ access globally in the Node.js runtime or limit the angular-expressions function to a single‑argument call pattern to reduce the attack surface.