CVE-2026-12866: Critical expr-eval Code Execution

Are You Affected?

CVE-2026-12866 affects the npm package expr-eval through version 2.0.2. The same vulnerable code is also distributed through the WebJars package org.webjars.npm:expr-eval.

Risk arises when an application allows attacker-controlled expressions, variables, formula data, or objects to reach the Expression.prototype.toJSFunction() API.

The package is not automatically exploitable merely because it is installed. Exposure depends on application behavior. Prioritize internet-facing services, APIs, administrative consoles, workflow engines, report builders, calculators, rule systems, and automation tools that accept expressions or formula-like input from users, tenants, integrations, or uploaded configuration.

Search both direct and transitive dependencies. A service may not import expr-eval in its own source tree but may receive it through a bundled frontend, a WebJars artifact, or another npm dependency. Treat any use of toJSFunction() with untrusted data as a high-risk path until reviewed.

Analyst’s Take: Package presence is only the starting point. The priority is determining whether attacker-controlled data can reach toJSFunction(). Because no patched version is listed, exposed call paths need containment or removal rather than a routine dependency upgrade.

The Fix, If You’re in a Hurry

No upstream fixed version was identified in the reviewed advisory material. The explicit affected range is expr-eval <= 2.0.2, and the GitHub Advisory Database lists no patched version. There is no verified upgrade target that can be provided as a safe fixed-version command.

The immediate mitigation is to prevent untrusted expressions and values from reaching toJSFunction(). If the application does not need code generation, remove that call from request-processing paths and use a safer, non-code-generating evaluation approach only after reviewing its security properties.

If the functionality is required, replace expr-eval with a maintained alternative that does not compile attacker-influenced input into executable JavaScript. Until that change is complete:

1. Disable public expression or formula features where possible.
2. Reject or constrain untrusted expressions before parsing.
3. Isolate the vulnerable processing component.
4. Remove unnecessary filesystem, network, credential, and process-execution access.
5. Review logs and rotate potentially exposed secrets.
6. Rebuild and redeploy from trusted artifacts.

If you use VPN or endpoint-security tools as part of broader containment, evaluate providers such as NordVPN or Malwarebytes according to your organization’s security and privacy requirements. These tools do not remediate the vulnerable dependency itself.

Technical Notes

Identify installed versions and call sites before changing production behavior:

npm ls expr-eval
npm audit --json
grep -RIn --exclude-dir=node_modules \
  -E 'toJSFunction[[:space:]]*\\(|expr-eval|new[[:space:]]+Function' .

For a WebJars deployment, inspect Maven dependencies:

mvn dependency:tree -Dincludes=org.webjars.npm:expr-eval

Do not treat a package-manager reinstall as remediation when no fixed version exists. Block or remove the vulnerable execution path, then rebuild and redeploy. If a temporary code change is possible, reject requests that invoke the affected feature and log the rejection for incident review.

Where processing cannot be removed, isolate it in a separate process or container with no unnecessary filesystem, network, credential, or process-execution access.

How This Vulnerability Works

The vulnerable behavior is associated with Expression.prototype.toJSFunction(). The API converts an expression into JavaScript source and compiles that source through the JavaScript Function constructor, commonly represented as new Function().

Input intended to remain within a mathematical or logical expression language can therefore influence code that executes in the application’s JavaScript runtime.

The issue is classified as CWE-94, Improper Control of Generation of Code. An application becomes exposed when it accepts attacker-controlled expressions or values and supplies them to the vulnerable API. The resulting function runs with the capabilities available to the host process rather than inside a complete security sandbox.

The published exploitation technique abuses value conversion during expression compilation. A crafted object can provide a custom toString() method. When the library converts the value while generating JavaScript, that method can execute Node.js operations. The documented proof of concept demonstrates filesystem access and command execution, including an attempt to run whoami.

A representative exploitation pattern is shown below. This is not a recommendation for testing against production systems; use only an isolated, disposable environment with authorization.

const { Parser } = require('expr-eval');

const parser = new Parser();
const expr = parser.parse('[cmd]');

const payload = {
  toString: () => {
    const fs = process.mainModule.require('fs');
    const cp = process.mainModule.require('child_process');

    fs.writeFileSync('expr-eval-poc.txt', 'PWNED');
    return cp.execSync('whoami').toString().trim();
  }
};

const fn = expr.toJSFunction('', { cmd: payload });
console.log(fn());

The exact post-exploitation impact depends on the Node.js process identity, container or host permissions, network access, secret injection, and available runtime APIs. Possible consequences include:

• Application-data theft
• Credential and environment-variable exposure
• Arbitrary file writes
• Child-process execution
• Lateral movement
• Full compromise of the service account

Severity, Explained

The reported CVSS base score is 9.8 Critical. That score indicates a vulnerability with potentially severe confidentiality, integrity, and availability consequences and a low-friction attack scenario.

It does not prove that every installation is remotely exploitable. Practical risk depends on whether an attacker can reach a code path that passes controlled data to toJSFunction().

The complete CVSS vector was not returned by the NVD response used for this assessment. Therefore, the exact values for attack vector, attack complexity, privileges required, user interaction, scope, and confidentiality, integrity, and availability impacts should not be reconstructed from the score alone. Authentication and privilege requirements are recorded here as unconfirmed rather than inferred.

Operationally, the important distinction is between package presence and reachable vulnerable functionality. A backend that uses expr-eval only with fixed, administrator-controlled formulas may have lower exposure than a public formula-builder API.

An application behind authentication can still be at serious risk if ordinary users, compromised accounts, tenants, or integrations can submit expressions.

Is It Being Exploited?

A public proof of concept exists. The Snyk advisory documents an exploitation pattern that uses toJSFunction() with a crafted object and demonstrates filesystem and command-execution behavior.

Public exploit material lowers the barrier to testing and adaptation, especially for attackers who can identify applications exposing expression-processing functionality.

Confirmed exploitation in the wild was not established by the reviewed sources. CISA’s Known Exploited Vulnerabilities catalog does not currently list CVE-2026-12866, and the assessment returned on_kev: false.

There is therefore no CISA KEV date-added entry, federal remediation deadline, required action, or ransomware-campaign flag for this CVE at the time of assessment.

CISA KEV status is not a clean bill of health. It reflects catalog status, not proof that exploitation is impossible or absent. Systems that allow attacker-controlled access to toJSFunction() remain high risk because the vulnerability provides a path to arbitrary JavaScript execution and public exploitation guidance is available.