A severe vulnerability has been discovered in the widely used JavaScript library `expr-eval`, which allows users to parse and evaluate mathematical expressions from untrusted input. The flaw can permit remote code execution (RCE), posing serious risks to the many projects that integrate the library. With more than 800,000 weekly downloads on the Node Package Manager (NPM) registry, the library is embedded in popular development ecosystems across web, server-side, and mobile environments.
Eval-Like Behavior in ‘expr-eval’ Leads to Code Execution
The vulnerability stems from `expr-eval`’s handling of custom functions provided by users. Versions prior to 2.0.2 allow attackers to inject malicious input that causes arbitrary code execution. If an application evaluates untrusted expressions and allows custom function registration without proper sanitization, an attacker could exploit these capabilities to run commands on the server.
Underlying Flaw Lies in Expression Compilation Mechanism
Security researchers discovered that expressions evaluated by `expr-eval` are compiled to JavaScript functions using the `new Function()` constructor, which is similar in behavior to the infamous `eval()` function. Given an attacker-controlled string, `new Function()` can execute arbitrary code in the context of the host application.
“The vulnerability essentially reduces to enabling untrusted users to pass partially structured JavaScript that gets executed on the server side,” said a security analyst involved in the discovery.
This scenario puts any `expr-eval` implementation that indirectly exposes the compilation of raw, user-controlled input at risk, especially if custom functions are used to expand expression capabilities in business logic.
Patch Released in Version 2.0.2 to Address Execution Risk
The developers of `expr-eval` reacted swiftly by publishing version 2.0.2, which addresses the flaw. The fix deprecates or alters the behavior that enabled misuse of the `new Function()` constructor within the parsing logic, effectively closing the vector for code injection.
Best Practices for Developers Using Math Expression Libraries
For professionals maintaining projects that use `expr-eval`, the following actions are strongly recommended:
- Upgrade to version 2.0.2 or later immediately
- Avoid passing user-controlled input directly to expression evaluators
- Conduct audits for use of `Function` or dynamic interpretation functions
- Apply strict input validation and allowlisting when registering functions
Applications parsing dynamic expressions — especially in financial, educational, or gaming platforms — should be particularly cautious, as they often rely on such libraries for critical logic evaluation and cannot risk the integrity of their runtime.
Broader Lessons on Embedded JavaScript Libraries
This incident underscores a growing concern in application security: the high potential for supply chain vulnerabilities through third-party libraries introduced via NPM or other package managers. With over 800,000 weekly consumers, a vulnerability in a library like `expr-eval` could cascade across hundreds of thousands of systems if left unpatched.
Supply Chain Trust Must Be Backed by Rigorous Review
Even widely used open-source libraries with strong reputations can include dangerous design patterns when applied incorrectly. The use of `new Function()` or similar execution primitives should raise red flags for security-conscious developers. While powerful, such features can become liabilities when they process untrusted input or act as extensibility layers that expose inner parsing logic to consumers.
As JavaScript continues to dominate both frontend and backend development, securing its component libraries becomes pivotal. Runtime code execution vulnerabilities such as this are particularly dangerous, not only because of their stealth, but also because they often lack easily detectable signatures until exploitation begins.
