This vulnerability exposes a dangerous false confidence pattern: JSONata included a hasOwnProperty check to block prototype pollution, but the check was bypassable through legitimate expression syntax like $spread and $string. The bypass requires no exotic constructs — every function used in the attack chain is a documented JSONata feature. The real exposure, however, is architectural, not syntactic. The vulnerability only achieves RCE because process.getBuiltinModule('child_process') is reachable from within JSONata evaluation — a Node.js integration that should never have been exposed to a data transformation library running in contexts where untrusted input flows through expressions.
If you're deploying JSONata in server-side contexts — API gateways, BFFs, serverless functions, config management systems — treat this as a deployment failure first, a library vulnerability second. The hasOwnProperty bypass is the symptom; the reachable builtin module is the disease. Patching to versions 1.8.8 or 2.2.1 is necessary, but verify the patch actually removes prototype chain access rather than just adding another bypassable guard. More critically, audit whether your deployment context ever exposed Node builtins to JSONata in the first place — if it did, the fix versions close one specific attack path, but the architectural decision to expose that capability may persist through other mechanisms.
The downstream risk compounds because JSONata is often a transitive dependency embedded in higher-level frameworks. Your application may be vulnerable even if you never explicitly installed it. Check your dependency trees for JSONata versions below 1.8.8 (Node.js) or 2.2.1 (browser), and treat any deployment where untrusted JSONata expressions could reach Node builtins as a full compromise until proven otherwise.