Topic starter
20/08/2026 5:31 pm
TL;DR: CVE-2026-12866 shows that expr-eval’s toJSFunction() API can turn untrusted formulas or variables into executable JavaScript inside Node.js, creating remote code execution risk in apps that treat expression builders, scoring logic, or workflow rules as data, according to Corgea. The boundary failure is architectural, not a simple patch-level issue: if attacker input reaches source generation, the application has already crossed into code execution territory.
Editorial analysis by NHI Mgmt Group, based on content published by Corgea: “CVE-2026-12866: `expr-eval` turns untrusted formulas into Node.js code execution”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: 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.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
20/08/2026 6:18 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: expr-eval CVE-2026-12866 shows formula engines can become code execution