Security advisory GHSA-jc85-fpwf-qm7x - request mitigation option to block function calls #290
Description
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