Attempt to fix CVE-2026-1615 vulnerability

[dfop02]

Attempt to Fix CVE-2026-1615: Arbitrary code injection in JSON Path expressions

Problem

The library is affected by CVE-2026-1615 (GHSA-87r5-mp6g-5w5j), mentioned on Issue 196. Script and filter expressions ?(...) and (...) were passed to static-eval with only the @ variable. static-eval is not a security boundary: it still evaluates CallExpression and allows dangerous property access (e.g. constructor, __proto__), so expressions like @.constructor.constructor('return process')().exit() could lead to RCE (Node) or XSS (browser) when paths come from untrusted input.

Solution

1. AST allowlist

Before calling static-eval, the expression AST is validated with isSafeAst(). Only a fixed set of node types is allowed: Literal, Identifier (only @), MemberExpression, UnaryExpression, BinaryExpression, LogicalExpression, ConditionalExpression, ArrayExpression, ObjectExpression. Any other node type is rejected.

2. Unsafe property names

Access to constructor, proto, and prototype is blocked at every MemberExpression so the path cannot reach Function or alter the prototype. The unsafe set is stored in an object built with Object.create(null) and bracket assignment so that __proto__ is a normal property (object literals treat __proto__ specially and would not add it as a key).

3. Explicit reject list (audit-friendly)

Dangerous node types are explicitly rejected instead of relying only on default-deny:

• CallExpression, NewExpression, FunctionExpression, ArrowFunctionExpression
• ThisExpression, AssignmentExpression, UpdateExpression, SequenceExpression
• TemplateLiteral, TemplateElement, TaggedTemplateExpression
• ReturnStatement, ExpressionStatement

4. ObjectExpression keys

For ObjectExpression, property keys are validated (Identifier and Literal). Object literals with unsafe keys (e.g. { "__proto__": @ }, { "constructor": @ }) are rejected.

5. Single allowed variable

The only allowed identifier is @; all others (e.g. process, eval, require, globalThis) are rejected.

If the expression is not safe, evaluation is not performed and an error is thrown: "Unsafe expression: script and filter expressions may only access the current node (@) with safe property names".

Testing

• All existing tests (query, filter, script, parse, security, slice, stringify, sugar) still pass.
• New tests under CVE-2026-1615 cover:
  • Constructor / proto / prototype (dot and bracket, including unicode escapes).
  • Chained constructor escape: @.foo["constructor"]["constructor"]("return process")().
  • ObjectExpression with unsafe keys: { "__proto__": @ }, { "constructor": @ }, { "prototype": @ }.
  • Calls: process.exit, require, eval, IIFE, new Function, method calls on @.
  • JSFuck-style payloads, sequence/comma expressions, template literals, arrow functions, assignment/update expressions.
  • That safe expressions (e.g. ?(@.price<10), $..book[(@.length-1)], @["@class"]) still work.

139 tests pass in total.

Files changed

• lib/handlers.js — Safe AST check (isSafeAst), unsafe-property map (Object.create(null) + bracket assignment), explicit reject list, ObjectExpression key validation.
• test/security.js — CVE-2026-1615 suite with regression and bypass tests.

Notes

JS is not my main language, so my apologies about any good-practice or patterns that I might miss here, I tried to solve the problem without generate any breaking change sanitizing the content that must be evaluated by the static-eval.

Please let me know if this approach makes sense or if there are additional improvements I should consider to ensure the issue is properly and safely resolved.

[adelimon]

This looks similar to what I came up with while trying to do this (just ran out of time). The idea is to have safe expressions that are allowed, and only allow those while blocking everything else.

[dfop02]

Yeah @adelimon , while testing this I kept thinking that maybe I was trying to cover too many possible unsafe cases. I did my best to think through different scenarios, but there’s always a chance something was missed.

Do you think it would make more sense to focus only on a clearly defined set of safe expressions instead? It feels like that might be simpler and easier to maintain than trying to block every possible unsafe pattern. I'm open to ideas and suggestions.

[ahedadja]

@dchester Can you we get your input on this PR please?