JSONata Advisory: Chained Prototype-Pollution Bugs Enable Arbitrary Code Execution (CVE-2026-77415)
What happened
A GitHub Security Advisory (GHSA-66mm-25pp-rfff, tracked as CVE-2026-77415) discloses that versions of the jsonata npm package prior to 2.2.1 (and 1.8.8 on the 1.x line) allow arbitrary code execution via crafted JSONata expressions. According to the advisory, the issue stems from three chainable weaknesses in the evaluator: the ability to overwrite the built-in $clone function to mutate objects during transforms, the ability to destructure internal JSONata functions/lambdas (e.g. via $merge.*), and an applyProcedure implementation that iterates proc.arguments with .forEach instead of Array.prototype.forEach. Chained together, these let a malicious expression reach into JavaScript internals and ultimately invoke child_process.execSync. The advisory includes a working proof-of-concept, and the maintainers state the fix was applied in PRs #799, #800, and #802, released in 2.2.1 and backported to 1.8.8. Exploit status is public PoC; a CVSS score was not listed in the advisory.
Why it matters
JSONata is a widely embedded query/transformation language used inside data pipelines, API gateways, low-code/iPaaS platforms, and backend services that evaluate user- or partner-supplied expressions against JSON payloads. Any application that evaluates untrusted JSONata expressions — directly or through a library/framework that embeds jsonata — is a candidate for remote code execution on the host running the evaluator, not just data manipulation. Because JSONata is frequently used precisely to let end users or downstream systems supply their own expressions, this is a realistic untrusted-input path in many deployments.
What defenders should watch for or do now
- Inventory dependencies (direct and transitive) for
jsonataand upgrade to2.2.1or later (or1.8.8on the 1.x line) wherever expressions from external or lower-trust sources are evaluated. - Identify any service, integration, or low-code platform that accepts user-supplied JSONata expressions as input and treat that input as untrusted until patched.
- As a hunting angle, review application/process logs for unexpected child-process spawns (e.g.
sh,bash, or shell invocations) originating from Node.js processes that host data-transformation or API-gateway services — this PoC's end state is a shell spawned viaexecSync. - Where patching is not immediately possible, avoid evaluating JSONata expressions from untrusted sources, and consider sandboxing/isolating the evaluation process (e.g. separate low-privilege worker, no filesystem/network access) as a compensating control.
- Watch for anomalous JSONata expressions in logs referencing internal identifiers such as
$clone,$merge,__lookupGetter__, or__proto__, which are consistent with the disclosed exploitation technique.
Developing intel
This is a same-day advisory and details may evolve as downstream projects assess exposure and issue their own patches. This note reflects only what is stated in the GitHub Security Advisory; for the authoritative technical details, PoC, and patch links, see the original advisory: GHSA-66mm-25pp-rfff.