Security advisory GHSA-jc85-fpwf-qm7x - request mitigation option to block function calls

[notnull-bmiller]

Hello maintainers and @silentmatt - after the advisory GHSA-jc85-fpwf-qm7x, our builds now fail on audit because expr-eval allows expressions to call any functions passed in via scope. We’re looking for either a patch or a documented mitigation that can be enforced at runtime. This just started happening today on a npm install.

Platform: Windows

Code: const { Parser } = require('expr-eval'); const parser = new Parser(); const expr = parser.parse('foo()'); console.log(expr.evaluate({ foo: () => 'called' })); // → 'called'

Expected A way to prevent expressions from invoking functions in the provided scope (treat functions as non-callable, or throw). Ideally a parser/runtime option we can set in production to enforce this. Actual

Any function on the scope can be invoked from the expression, which is unsafe when expressions are user-provided and the scope may contain helpers or richer objects. Impact

CI/CD blocks on npm audit (high severity). We can sanitize our scope to primitives only as a workaround, but we need a library-level control to enforce safety and satisfy audit policies. Requests

Add a configuration flag (e.g., allowFunctionCalls: false) that: Rejects function values in scope OR Treats them as non-callable (accessing/calling throws). Optionally add another flag to disallow member access (e.g., allowMemberAccess: false). Consider making the safe defaults true in the next major version. Document recommended mitigations for existing users. Workarounds we’re using

Sanitize scope to only numbers/strings/booleans. Ensure no functions/objects/arrays are passed to evaluate. Still, audit remains red without a library-level mitigation.

Is there a planned fix or an accepted design for a runtime option to block function calls? A short-term patch with a flag would unblock many teams while preserving current behavior behind an opt-in.

Thank you! Bobby