Security · 21 Aug 2026 · Rob Nidschelm

The “Safe” Expression Language Could Spawn a Shell. Three JSONata Flaws Turned Queries Into Code Execution

A language designed to query and transform JSON could become a route to the operating-system shell when an application let an attacker control the expression being evaluated. Three critical JSONata vulnerabilities demonstrate how quickly a convenient data-processing boundary can turn into host-level code execution.

The flaws are tracked as CVE-2026-77413, CVE-2026-77414 and CVE-2026-77415. Each has a critical CVSS 4.0 score of 9.3. The upstream advisories include working proof-of-concept expressions that reach Node.js’s child_process module and start a shell.

There is an important limit to the finding. Supplying ordinary JSON data is not enough. An attacker must be able to control, influence or select the JSONata expression that the host evaluates. That condition still matters across workflow engines, integration platforms, transformation services, low-code products and multi-tenant applications where expressions are accepted as rules, filters or mappings.

One package exposed three escape routes

JSONata presents a compact expression language for selecting, combining and transforming JSON. Applications can embed the JavaScript implementation and evaluate expressions against data without asking users to write full JavaScript programs. The security assumption is that the expression remains inside that restricted language.

The three advisories document different ways to cross that boundary:

• CVE-2026-77413: the lookup function did not verify that a requested property belonged directly to the object. A crafted expression could reach inherited prototype members, constructor access and ultimately the host process. Versions before 1.8.8 and 2.x versions before 2.2.0 are affected. The direct fixes are 1.8.8 and 2.2.0.
• CVE-2026-77414: a check in environment.lookup could itself be bypassed. The expression could replace the expected property-checking behaviour and regain access to dangerous constructors. Versions before 1.8.8 and 2.x versions before 2.2.1 are affected. The fixes are 1.8.8 and 2.2.1.
• CVE-2026-77415: several language behaviours could be chained. The advisory describes overwriting $clone, manipulating JSONata function objects and abusing a method call that trusted an object-supplied forEach. Versions before 1.8.8 and 2.x versions before 2.2.1 are affected. The fixes are 1.8.8 and 2.2.1.

The first correction was therefore not the end of the problem for the 2.x branch. Version 2.2.0 addressed one route, while the two additional escapes required 2.2.1. Administrators should not treat 2.2.0 as the safe destination for this vulnerability set.

The expression is the security boundary

The word “remote” in a severity score can be misleading without the deployment context. JSONata is a library, not a network service that automatically listens for hostile traffic. Exploitation becomes remote when a network-facing application passes attacker-controlled expressions to the library.

That can happen in less obvious places than a field labelled “run a query.” A SaaS product may let customers define transformations for incoming records. An API gateway may accept filters. A workflow tool may store mappings in tenant-controlled configuration. A reporting system may build expressions from request parameters. A support or operations interface may allow advanced searches that are later evaluated by a Node.js service.

Defenders therefore need to inventory expression input paths, not only package versions. A dependency scanner can show where JSONata is installed. It cannot show whether an untrusted user can choose the expression, whether the application assembles expressions from untrusted fragments or whether a stored expression crosses between tenants.

Public proof of concept shortened the path to exploitation

The upstream GitHub advisories were published on 13 July 2026 and entered the reviewed GitHub Advisory Database on 21 August. They do not stop at a theoretical description. Each provides a complete expression showing how the restricted evaluator can reach Node.js process functionality and execute a shell command.

CISA’s SSVC enrichment for the first record classified exploitation as proof of concept, automatable as yes and technical impact as total on 24 August. That is not evidence of malicious activity in the wild. It is evidence that the exploit path is public, concrete and suitable for automation when an exposed application accepts hostile expressions.

No confirmed malicious exploitation was identified while this article was prepared. Organisations should keep that distinction clear. Public code changes defender urgency because it lowers the work required to test vulnerable applications, but it does not prove that attackers have already compromised them.

The package’s reach is larger than its name recognition

JSONata is a specialist component, but its distribution is substantial. The npm package page showed 1,716,283 weekly downloads and 566 dependent packages on 25 August. Those figures are not an installation count and do not reveal how many deployments evaluate untrusted expressions. They do show why direct application inventories will miss part of the exposure.

A product may inherit JSONata through another library, an integration connector or a bundled workflow component. The vulnerable package can therefore sit several layers below the feature that accepts a mapping or rule. Software vendors should search lockfiles and built artefacts, while operators should ask suppliers whether expression evaluation occurs in a privileged service.

Patch the package, then reduce the blast radius

The safest 2.x destination is the current 2.2.2 release or later. Version 2.2.1 contains the complete fixes for all three code-execution paths, and 2.2.2 is the current npm release observed during verification. Organisations that must remain on the 1.x branch should use at least 1.8.9. The code-execution fixes landed in 1.8.8, while 1.8.9 also includes a separate fix for resource exhaustion in $toMillis.

Where an immediate upgrade is not possible, applications should stop evaluating expressions supplied by untrusted users. A fixed allow-list of server-owned expressions is stronger than trying to remove a few suspicious property names from a hostile language string. The published chains use several language features, and a blacklist can miss an equivalent route.

• Find every copy. Search direct and transitive dependencies, lockfiles, container images, serverless bundles and vendored JavaScript.
• Map expression provenance. Record whether expressions come from application code, administrators, customers, API requests or stored tenant configuration.
• Upgrade completely. Move 2.x deployments to 2.2.1 or later, preferably 2.2.2. Move maintained 1.x deployments to 1.8.9 or later.
• Constrain the process. Run transformation workers without unnecessary filesystem, network, cloud-metadata or secret access. A language escape inherits the privileges of the Node.js host.
• Review historical activity. Look for unexpected child processes, shell execution, unusual outbound connections and expression failures around services that evaluated externally influenced rules.
• Test tenant boundaries. Confirm that one tenant cannot create or select an expression evaluated with another tenant’s data or credentials.

A safe language is only as safe as its escape surface

The important lesson is not that every JSONata user was remotely exploitable. It is that an expression engine becomes part of the application’s code-execution boundary the moment untrusted users can influence what it evaluates.

JSONata was useful precisely because it offered more power than a fixed field selector. The three vulnerabilities show the security cost of that power when prototype access, function objects and host-language behaviour remain reachable in unexpected combinations. Patch management closes the known chains. Process isolation and strict control over expression provenance reduce the damage when the next chain is found.

Sources

• JSONata advisory GHSA-8gq3-vp5j-2grp, published 13 July 2026, time not provided.
• JSONata advisory GHSA-2943-5xfg-gq5f, published 13 July 2026, time not provided.
• JSONata advisory GHSA-66mm-25pp-rfff, published 13 July 2026, time not provided.
• NVD record and CISA SSVC enrichment, CVE received 21 August 2026 at 17:17:07 UTC and updated 24 August 2026.
• JSONata on npm, package reach verified 25 August 2026.
• JSONata resource-exhaustion advisory, published 29 May 2026.