Last Week in AppSec for 18. November 2025

Last week in AppSec included lessons like:

• eval sandboxing is hard: NPM module expr-eval, a “safer” eval for math expressions with an arbitrary code injection (CVE-2025-12735)
• password workflow logic needs proper security review: Flowise, a visual designer for agentic AI workflows, accidentally lets attackers change user passwords GHSA-fjh6-8679-9pch

NPM mathematics modules expr-eval code injection CVE-2025-12735

The NPM module expr-eval (extremely popular, at over 777,000 downloads per week) aims to evaluate math expressions provided by users inside a sandbox, with the explict goal of providing “a safer and more math-oriented alternative” to using the built-in eval, turns out to not be all that much safer. All versions through and including 2.0.2 are affected by CVE-2025-12735 (CVSSv3 9.8 per reporter): a weakness in input validation that allows an attacker to escape the sandbox and execute arbitrary code. Researchers supplied a patch which has been merged, but no new release has been made to NPM; switching to [email protected] or adding the merged version as 3.0.0 into your local pacakge repository are the paths to repair.

A successful attack against this CVE only requires the adversary to sneak something like a function or a cleverly-encoded prototype into the variables that are evalauted by the expr-eval module’s evaluate() method; these are well-known and well-documented tricks. The ease and scope of this attack means that applications which implement expr-eval and are exposed over a network likely have an RCE (Remote Code Execution) vulnerability. This type of attack can be somewhat mitigated by WAF rules, but doing so effectively is often more difficult than repair.

Flowise AI agent designer lets anyone reset user passwords

The visual designer for agentic AI workflows, Flowise has a nasty vuln documented in GHSA-fjh6-8679-9pch (CVSSv3 8.3): an attacker can change a users’ password without knowing the old one. Fortunately, exploitation requires authentication (using bypasses like XSS in other parts of the UI or buggy forgotten-password flows like the one Flowise fixed in version 3.0.6, [CVE-2025-58434][202] (CVSSv3 9.8)), so an attacker must first do something like steal an active session; however, once that’s done, the attacker can then persist their access by changing the user’s password to a known value. Upgrade to 3.0.10 to repair, especially if you’re on a version older than 3.0.6.

What should happen when an authenticated user wishes to change a password is that the system requires confirmation of the existing password. The UI looks like it requires this, but would accept the new password without confirming the old password as long as the sesion was valid.

This is particularly bad if you have versions older than 3.0.6, as there are known vulnerabilities in those versions that make it easier for attackers to gain the initial authenticated access they’ll require. If you see evidence of exploitation, require users to change passwords.