expr-eval CVE-2026-12866 shows formula engines can become code execution

At a glance

What this is: CVE-2026-12866 shows that expr-eval’s toJSFunction() can convert attacker-controlled formulas or variables into executable JavaScript in Node.js.

Why it matters: It matters because teams often embed formula engines in scoring, workflow, and admin paths that are treated as data handling, not code execution, which creates a hidden RCE boundary.

Context

Formula engines are often used to let users define rules without giving them direct code access, but that convenience breaks when the engine emits JavaScript and compiles it inside the application process. In this case, the core issue is not a parsing bug in isolation, but a trust-boundary failure between untrusted input and runtime code generation.

For IAM, PAM, and NHI governance teams, the identity angle is indirect but real: a Node.js process that can execute attacker-controlled formulas may also hold cloud credentials, CI tokens, API keys, or deployment secrets. That makes the formula feature part of the same control surface as privileged service accounts and runtime secrets.

Key questions

Q: What breaks when untrusted formulas are compiled into JavaScript?

A: The trust boundary breaks because the application stops interpreting data and starts generating executable code inside the runtime. If attacker-controlled expressions or variables reach a compiler such as new Function(), the result is not just a bad calculation. It is code execution with the privileges of the host process, which can expose secrets, local files, and network reachability.

Q: Why do formula engines create a code execution risk in Node.js?

A: Node.js makes the impact worse because runtime code execution can reach built-in modules, environment variables, and other process-level capabilities. A formula engine that emits JavaScript source and compiles it inside the same process can therefore turn a business rule into an RCE path. The risk is highest when the service also holds credentials or has broad network access.

Q: How do security teams know if a formula engine is too privileged?

A: Look for three signals: reachable host commands, access to runtime libraries or embedded hooks, and network or filesystem paths that exceed the platform’s business need. If any of those are present, the formula engine is operating like a privileged service rather than a bounded calculation layer. That is a governance problem, not just a code issue.

Q: What should teams do immediately if attacker-controlled input reached formula compilation?

A: Assume the process executed attacker-supplied code and contain it as a host compromise. Rotate any secrets reachable from that Node.js service, review logs for suspicious formula edits, inspect outbound connections, and verify whether the expression runner had access to deployment tokens, cloud credentials, or sensitive internal APIs before restoring service.

Technical breakdown

Why toJSFunction() crosses from expression evaluation into code generation

Expression engines usually operate on data structures or interpreted syntax, which keeps untrusted input out of the runtime compiler. expr-eval’s toJSFunction() is different because it simplifies the expression, converts the result into JavaScript source, and then feeds that string into new Function(). Once variables influence simplification, the application is no longer evaluating math safely. It is assembling code from attacker-influenced content and handing that code to the Node.js runtime. That is why the same feature can be harmless for trusted formulas but dangerous for anything user-controlled.

Practical implication: Treat any path that reaches new Function() from untrusted formulas as code execution, not expression evaluation.

How attacker-controlled variables become executable payloads

The vulnerable boundary is not limited to the expression string itself. In the reported pattern, the variables object passed into simplification can contain values whose string conversion is attacker-controlled, which means the generated source can be shaped indirectly. That is especially risky in applications that store formulas, reload them later, and convert them into callable functions for performance. The implementation detail matters: source generation happens inside the same process that owns application state, so any successful injection inherits the process context, including environment variables, filesystem access, and outbound network reach.

Practical implication: Block non-primitive inputs from formula compilation paths and review every place where saved expressions are later precompiled.

Why Node.js makes the impact materially worse

In Node.js, runtime code generation is not just a local logic issue. If an attacker reaches new Function(), they can often reach process-level capabilities, built-in modules, and anything the host process can access. That is why proof-of-concept payloads aim at child_process and similar primitives. The real exposure is the process privilege set, not the formula engine itself. If the service runs with cloud credentials, CI tokens, signing keys, or broad network access, the formula feature becomes a route into those assets. In practical terms, this is an application-layer RCE problem with identity and secret-management consequences.

Practical implication: Minimise the privileges and secrets available to any Node.js service that compiles dynamic expressions.

Threat narrative

Attacker objective: The attacker’s objective is remote code execution inside the Node.js service so they can execute commands and reach secrets available to that process.

1. Entry occurs when an application accepts attacker-controlled formulas or variables and passes them into expr-eval for later compilation.
2. Credential access follows once the generated JavaScript runs inside the Node.js process and can reach process-level secrets or built-in modules.
3. Impact occurs when the attacker executes arbitrary commands or reads sensitive runtime data through the compromised application context.

Breaches seen in the wild

• Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Formula engines that compile into source code are not safe data features; they are execution surfaces. The problem is not limited to expr-eval. Any system that turns untrusted expressions into runtime code has crossed the same boundary, even if the business use case looks like scoring, pricing, or workflow logic. Practitioners should treat these engines as part of the application’s code-execution attack surface, not as harmless configuration helpers.

Dynamic formula compilation creates a secrets exposure problem as much as a code execution problem. Once a Node.js process can run attacker-supplied JavaScript, the blast radius depends on what the process can reach. That brings NHI governance into the picture because service credentials, API keys, and deployment tokens are often sitting in the same runtime. The control failure is not just insecure input handling; it is over-trusting a privileged execution context.

Source generation inside business logic is an architectural trust error, not a patch-size defect. The presence or absence of a fixed upstream release does not change the core issue if the design still feeds untrusted input into new Function(). Teams need to identify every formula compiler, rule engine, and low-code helper that can be influenced by external users or low-trust operators. The practitioner lesson is to remove the dangerous pattern, not to assume version tracking alone resolves it.

Expression runners should be treated like privileged workloads with tightly bounded identity and secret scope. If dynamic formulas are unavoidable, isolate them from the main application process and deny them ambient access to credentials, filesystem state, and internal network reach. That framing aligns with NHI governance because the service account running the formula engine becomes a machine identity that needs deliberate scoping, not inherited trust.

What this signals

Dynamic formula engines need the same governance discipline as other privileged runtime components. If a Node.js service can turn formulas into code, then the service account, secrets, and network permissions around it become part of the risk model. Teams should inventory these execution points as machine-identity-bound workloads and apply tighter runtime scoping than they would for ordinary application logic.

Formula compilation should be treated as a trust transition point. The moment untrusted input becomes source code, traditional input validation is no longer enough. NHI and platform teams should focus on where that transition happens, because the control question is not only what the formula computes but what the runtime is allowed to do after compilation.

For practitioners

• Remove dynamic source generation from untrusted formula paths Eliminate calls to toJSFunction() wherever expressions or variable maps can be influenced by users, customers, plugins, or uploaded configuration.
• Inventory every expr-eval usage path Search codebases, dependency manifests, and runtime helpers for expr-eval and toJSFunction() so you can separate trusted developer-only usage from externally influenced execution.
• Isolate formula execution from privileged application runtime Run any unavoidable dynamic expression engine in a constrained worker with no ambient cloud credentials, minimal filesystem access, and tightly controlled egress.
• Restrict variable types before compilation Allow only primitive values into formula compilation and reject objects that can alter string conversion, coercion, or generated source content.
• Treat the host as compromised if attacker input reached compilation Rotate secrets reachable from the affected Node.js process, inspect logs for formula edits, and review outbound activity and shell telemetry from the exposure window.

Key takeaways

• expr-eval CVE-2026-12866 shows that a formula engine can become an RCE boundary when untrusted input is compiled into JavaScript inside Node.js.
• The risk is architectural because the vulnerable pattern converts data into executable source within the same process that often holds secrets and network access.
• Removing dangerous compilation paths, isolating execution, and treating the host as compromised after exposure are the controls that change the outcome.

Key terms

• Runtime Code Generation: Runtime code generation is the practice of turning data or metadata into executable program code while the application is running. It improves flexibility and performance, but it becomes dangerous when untrusted inputs can influence the generated source or its execution path.
• Formula Engine: A formula engine is the runtime that evaluates user-authored expressions inside a business application. In a spreadsheet platform, it may transform data, call functions, and interact with supporting libraries, which means it must be governed as code execution whenever untrusted input is allowed.
• Trust Boundary: A trust boundary is the point where one system’s authority should stop and another system’s authority should begin. For internal automation, weak trust boundaries let monitoring, remediation, and execution share privileges that should have remained separate.
• Node.js Process Privilege: Node.js process privilege is the set of files, environment variables, modules, network paths, and secrets available to a running Node application. If attacker-controlled code executes inside that process, the effective impact is governed by those privileges rather than by the formula engine itself.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.