CVE-2026-1615: When "Static" Evaluation Wasn't That Static

jsonpath, the library that calls itself "Robust / safe JSONPath engine for Node.js" in its own README, spent years feeding attacker-controlled JavaScript ASTs into static-eval — a module whose maintainer has repeatedly said it is not a sandbox. The fix in 1.3.0 is an AST allow-list. The lesson is older than the bug.

The advisory in plain English

JSONPath has two corners of the syntax that, in this library, mean "evaluate this fragment as JavaScript against the current node": filter expressions ($..book[?(@.price < 10)]) and script expressions ($..book[(@.length-1)]). The contents of those parens were never restricted to comparison or arithmetic. They were lexed and parsed by a full JavaScript parser (a patched esprima), and the resulting expression AST was then handed to static-eval to be reduced to a value.

If you control the JSONPath string, you control that AST. And if static-eval is willing to walk node types like MemberExpression, CallExpression, and NewExpression against real runtime values, then "evaluate this comparison expression" quietly becomes "evaluate this arbitrary JavaScript expression." On Node.js that's RCE; in a browser shim, that's XSS. CVSS pinned it at 9.8 (CVE-2025-64769) because every public entry point — .query, .nodes, .paths, .value, .parent, .apply — is affected once a single filter or script expression is reachable from user input.

The flawed function

The actual gate was four lines, and has been essentially unchanged for years. From git show 491e2e0~1:lib/handlers.js (i.e. the pre-fix version), bottom of the file:

function evaluate() {
  try { return _evaluate.apply(this, arguments) }
  catch (e) { }
}

That _evaluate is require('static-eval'). There is no filtering, no allow-list, no inspection of what the AST actually contains. Any parsed expression that aesprim (esprima with @ accepted as an identifier) produces is passed through, and any value static-eval returns is returned. The catch (e) {} is the only "safety" present, and it only suppresses errors — it does not stop side effects that have already executed before an error is thrown.

The call sites tell the rest of the story. Same file, subscript-child-filter_expression:

// slice out the expression from ?(expression)
var src = component.expression.value.slice(2, -1);
var ast = aesprim.parse(src).body[0].expression;

var passable = function(key, value) {
  return evaluate(ast, { '@': value });
}

And member-child-script_expression follows the same shape via the helper eval_recurse, which calls evaluate() internally and then substitutes the evaluated value back into another JSONPath that gets re-parsed and re-walked — so the same allow-list now gates it. Two parsers, one evaluator, zero validation.

Why the check was insufficient

The check wasn't insufficient — it didn't exist. The architectural mistake was assuming that a module named static-eval is a static evaluator in the sense of "constant-folding for trusted code." It isn't, and never was. static-eval's README and issue tracker have for years made clear it evaluates JS ASTs against a caller-supplied scope and is not intended as a sandbox. Among the node types it happily walks:

• MemberExpression — dereferences properties at runtime against whatever object it finds.
• CallExpression — invokes a callable value with reduced arguments.
• NewExpression — instantiates via new.
• ObjectExpression, ArrayExpression, BinaryExpression, LogicalExpression, ConditionalExpression — the building blocks of an expression language.

Hand that a scope that contains any JavaScript value, and the well-known JS sandbox-escape primitive immediately applies: starting from any object you can reach its .constructor, from any function you can reach .constructor again, and that is Function, the runtime compiler. From there you have parity with eval. This is the same constructor-chain escape that produced a string of vm2 CVEs and ultimately motivated vm2's discontinuation in 2023, with isolated-vm now the commonly recommended alternative; jsonpath just had it the whole time without ever advertising a sandbox at all. The library's own new test file ratifies this — quoting a single line from test/security.js (post-fix, asserting the rejection of the pattern, not how to use it):

test('rejects chained constructor.constructor call: ' +
     '@.foo["constructor"]["constructor"](...)()', function() { /* ... */ });

The point isn't that "constructor.constructor" is some exotic trick. The point is that nothing in evaluate() ever asked whether the AST contained a CallExpression at all. Once you've parsed user input with a full ECMAScript parser and handed it to an evaluator that respects call nodes, you've made the language Turing-complete with respect to your scope. There is no clever runtime check that retroactively makes that decision safe — you must restrict the grammar before you evaluate, not after.

What the fix changed

PR #197 (491e2e0, merged as b61111f07ac1a8d0f3133b5fc51438ecb76a6c39) adds a ~150-line allow-list walker to lib/handlers.js called isSafeAst, and changes evaluate to refuse anything that doesn't pass. The new gate is a positive list — every node type that gets a case is one the library has decided to support; everything else falls through to default: return false.

The structural pieces:

case 'Identifier':
  // Only allow the special scope identifier
  return node.name === '@';

Identifiers are restricted to literally @. There is no way to name process, global, require, globalThis, or any user-defined free variable.

case 'CallExpression':
case 'NewExpression':
case 'FunctionExpression':
case 'ArrowFunctionExpression':
case 'ThisExpression':
case 'AssignmentExpression':
case 'UpdateExpression':
case 'SequenceExpression':
case 'TemplateLiteral':
case 'TemplateElement':
case 'TaggedTemplateExpression':
case 'ReturnStatement':
case 'ExpressionStatement':
  return false;

The author explicitly lists every escape vector instead of relying solely on default: return false. The comment is the right one: "do not rely on default deny; list each code-execution / escape vector." If a future esprima version invents WhateverExpression that can call functions, default-deny will still reject it, but the explicit list documents intent.

MemberExpression is allowed, but with a property-name check against an Object.create(null)-backed table:

var UNSAFE_PROPERTY_NAMES = Object.create(null);
UNSAFE_PROPERTY_NAMES['constructor'] = true;
UNSAFE_PROPERTY_NAMES['__proto__']  = true;
UNSAFE_PROPERTY_NAMES['prototype']  = true;

And the gate is applied for both obj.constructor and obj["constructor"] — non-computed identifier names and computed Literal keys are both stringified and rejected if they match. The Object.create(null) is the right detail; a plain object would either reject benign names like toString via prototype inheritance (the lookup resolves to Object.prototype.toString, which is truthy), or silently fail to record __proto__ because the assignment hits the __proto__ setter instead of creating an own property.

The evaluate wrapper itself is now three lines longer and three lines smarter:

function evaluate(ast, scope) {
  if (!isSafeAst(ast)) {
    throw new Error('Unsafe expression: ...');
  }
  try { return _evaluate(ast, scope) }
  catch (e) { }
}

The accompanying test/security.js adds ~190 lines of negative tests — bracket vs. dot, unicode escapes (@["\u0063onstructor"]), IIFEs, tagged templates, sequence expressions, JSFuck-style index chains (encoding arbitrary JS using only []()+! arithmetic on strings), which isSafeAst rejects automatically because the encoded program still parses to CallExpression / disallowed Identifier nodes — each one asserting /Unsafe expression/ is thrown. It's the kind of test suite you write when you know the parser will accept more syntax than you remembered.

The lesson

jsonpath has shipped a fix and is at 1.3.0. Three things deserve to be written down:

1. "Static eval" is a name, not a guarantee. A module that walks a JS AST and resolves member access, calls, and constructors against a scope object is an interpreter. Treat anything you hand it as code, not as data.
2. If you parse it with a full JS parser, you must restrict the grammar yourself before evaluation. A try/catch around the evaluator is not restriction — it suppresses errors that arrive after side effects. Allow-list the AST node types, validate property names, then call the evaluator.
3. Default deny, explicit deny, explicit allow — in that order. The new isSafeAst is a textbook example: explicit cases for every allowed type, explicit cases for every known dangerous type, and default: return false. Belt, suspenders, and a note pinned to the suspenders saying "these are suspenders."

RFC 9535 (the 2024 IETF JSONPath standard) never required Turing-completeness inside ?(...); its filter grammar is deliberately non-Turing-complete, restricted to comparisons, basic arithmetic, and a small set of well-defined functions. Most consumers use it for @.price < 10. A decade of "but it's fine because static-eval" papered over the fact that every install of jsonpath was, in practice, eval() with extra steps.

References

• Fix commit: https://github.com/dchester/jsonpath/commit/b61111f07ac1a8d0f3133b5fc51438ecb76a6c39
• Pre-fix vulnerable line (handlers.js L243 at c1dd8ec): https://github.com/dchester/jsonpath/blob/c1dd8ec74034fb0375233abb5fdbec51ac317b4b/lib/handlers.js#L243
• CVE-2025-64769 (NVD): https://nvd.nist.gov/vuln/detail/CVE-2025-64769
• Snyk advisory (npm/JS): https://security.snyk.io/vuln/SNYK-JS-JSONPATH-13645034
• Snyk advisory (Maven/WebJars mirror): https://security.snyk.io/vuln/SNYK-JAVA-ORGWEBJARSNPM-15141219
• static-eval sandboxing caveats (issue thread): https://github.com/browserify/static-eval/issues/19