CVE-2026-41139

What it actually does

mathjs versions 13.1.0 through 15.1.x allow the expression parser (evaluate/parse/compile paths) to run attacker-controlled JavaScript in the host Node.js or browser process. Successful abuse is remote code execution with high impact on confidentiality, integrity, and availability of the application runtime (CVSS 8.8; network, low privileges, no user interaction).

Why it matters to the business

Any product that evaluates untrusted formulas, calculators, or user-defined math with mathjs can be fully compromised: data theft, service disruption, and use of the host as a foothold. The issue has been public for about 144 days, is not in CISA KEV, and has no reported ransomware use, but EPSS has risen about 38% over 30 days (to ~0.008). Treat as a high-severity library RCE until every dependent is on a patched release.

How an attack unfolds

An attacker finds an application that passes untrusted input into mathjs expression APIs. They submit a crafted expression that the vulnerable parser treats as executable JavaScript rather than a constrained math formula. That code runs with the privileges of the application process, after which the attacker can read secrets, alter data, or persist. No named threat actors or mature public exploits are associated with this CVE at this time.

How to fix it

Upgrade mathjs to 15.2.0 or later across all direct and transitive dependents (npm: mathjs). Rebuild and redeploy so no runtime still loads 13.1.0–15.1.x. Until patched, do not pass untrusted input to math.evaluate, math.parse, math.compile, or equivalent parser APIs; restrict those APIs to fully trusted expressions only. Inventory lockfiles and container images for the affected range and block new installs of unpatched versions.

How to confirm the fix worked

Confirm lockfiles, installed package trees, and runtime images show mathjs >= 15.2.0 and no remaining 13.1.0–15.1.x copies. Search code and configs for evaluate/parse/compile of user, file, or API input. After upgrade, regression-test legitimate formulas only; do not use exploit payloads. Recheck production, CI, and serverless bundles, including nested node_modules.

Typical attack path

1. Locate an application or API that evaluates user-supplied expressions with mathjs 13.1.0–15.1.x.
2. Submit a crafted expression to parse, compile, or evaluate interfaces (directly or nested in stored formulas).
3. Trigger parser evaluation so attacker-controlled JavaScript runs in the application process.
4. Use that execution to steal credentials or data, change application state, or establish persistence.
5. Move to other systems or maintain access using the compromised runtime.

How to detect it

There is no KEV listing, no named actor activity, and exploit maturity is none, so do not expect a unique public implant. Hunt historically for unpatched mathjs 13.1.0–15.1.x in deployed apps that accept formulas, then look for post-exploitation on those hosts: unexpected child processes from Node, outbound connections from formula-evaluation services, and sudden secrets or data access around formula-submission endpoints. Review application logs for anomalous expression submissions to evaluate/parse/compile APIs. Absence of those signals does not prove non-exploitation.

What your security team should do

• Patch mathjs to 15.2.0+ everywhere it is used, including transitive dependencies, as the first priority.
• Inventory all services that evaluate untrusted math or user-defined formulas and treat those as internet-facing RCE risk until verified patched.
• Stop evaluating untrusted expressions with mathjs; allowlist trusted formulas or isolate evaluation if product design requires it.
• Watch EPSS and exploit-intel; there is no KEV listing and exploit maturity is none, but the score is trending up.
• Prioritize internet-exposed calculators, plugins, and multi-tenant formula features for upgrade and review.