CVE-2026-40897

What it actually does

In math.js 13.1.1 through versions before 15.2.0, the expression parser does not adequately constrain evaluation of attacker-controlled expressions. A user who can submit expressions for evaluation can cause arbitrary JavaScript to run in the same process as the application (Node.js or browser), with the application's privileges. This is remote code execution in the application context: confidentiality, integrity, and availability of the hosting process can all be lost.

Why it matters to the business

Any product that lets customers, tenants, or untrusted users evaluate math expressions with math.js can be fully taken over: data theft, tampering of calculations or records, service disruption, and follow-on abuse of connected systems. math.js is a widely used JavaScript/Node math library, so exposure may exist in calculators, analytics, education, finance, and low-code features. CVSS is 8.8 (network, low complexity, low privileges, no user interaction). It is not in CISA KEV, ransomware use is not reported, and exploit maturity is none; EPSS remains low (~0.0076) but rose about 38% over 30 days. The issue has been public for roughly five months—patching should still be treated as a priority for any internet-facing or multi-user expression feature.

How an attack unfolds

An attacker locates an application that evaluates user-supplied strings with the math.js expression parser (for example a formula field, calculator API, or notebook). They authenticate if the feature requires a low-privilege account, then submit an expression designed to break out of intended math-only evaluation and run host JavaScript. Successful evaluation executes attacker-chosen code with the rights of the application process, which can be used to read secrets, change data, or persist access. No named threat actors or in-the-wild campaigns are indicated in the provided intelligence; public exploit maturity is none, so opportunistic scanning of expression-evaluation endpoints is the more likely near-term path than a known mass-exploit kit.

How to fix it

Upgrade math.js to 15.2.0 or later in every application and lockfile (npm/yarn/pnpm) that uses the expression parser. Treat 13.1.1 through 15.1.x as vulnerable. After upgrading, rebuild and redeploy so runtime bundles and containers are not still shipping an old copy. Until you can upgrade, do not evaluate untrusted or user-supplied expressions with math.js; restrict expression features to trusted operators, or disable the parser/evaluate path. Do not rely on ad-hoc input filters as a substitute for the vendor fix. Pin and verify the resolved version in production images and serverless layers, including transitive dependents.

How to confirm the fix worked

Inventory all direct and transitive uses of the mathjs package (lockfiles, SBOM, container image scans, browser bundles). Confirm the resolved version is 15.2.0 or newer everywhere expressions are evaluated. On a staging build, verify package.json/lockfile and runtime require/import resolve to the fixed release. Confirm that user-facing formula or calculator features still function with legitimate math only. Recheck deployed artifacts (node_modules, bundled JS, Lambda layers) so an old copy is not left in production.

Typical attack path

1. Discover an application or API that evaluates untrusted input with the math.js expression parser
2. Obtain whatever low privilege the feature requires (often a normal user account; no extra interaction needed)
3. Submit a crafted expression that the parser treats as executable JavaScript rather than pure math
4. Run arbitrary code in the application process and abuse its access to data, credentials, or downstream services
5. Optionally persist or move laterally using whatever the compromised process can reach

How to detect it

There are no public in-the-wild campaigns or named actors tied to this CVE, and exploit maturity is none, so do not expect a unique malware family. Hunt historically around features that accept formulas or expressions: web and API access logs to evaluate/parse/compute endpoints; application logs of expression text; Node.js process crashes, unexpected child processes, or outbound connections originating from the app that evaluates math. Compare those events to the window since publication (from 2026-04-24 onward). Look for users submitting unusually long or non-mathematical expressions, repeated failures followed by success, or evaluation requests from accounts that rarely use the feature. On hosts running Node, review process creation, file writes under the application user, and secret-file access after expression requests. Browser-side impact is limited to that origin unless the same parser runs on a server. Absence of known exploit signatures means detection is behavioral, not signature-based.

What your security team should do

• Immediately identify services that evaluate user-controlled expressions with math.js and schedule upgrade to 15.2.0+
• Block or disable untrusted expression evaluation until those services are patched and redeployed
• Use SBOM and lockfile scanning to find transitive mathjs 13.1.1–15.1.x, including front-end bundles
• Prioritize internet-facing and multi-tenant formula/calculator features over internal-only tools
• After patching, review application logs around expression-evaluation endpoints for abuse during the ~158 days since disclosure
• Do not wait for KEV listing; treat this as a standard high-severity RCE in a common library despite currently low EPSS