CVE-2026-85625 in sift.js
Summary
by MITRE • 09/04/2026
sift (sift.js) 17.1.3 enumerates query keys with for...in, which walks the object prototype chain, and dispatches any matched operator key including $where. The $where operation compiles a string value into a function using new Function unless CSP_ENABLED is set (not set by default). As a result, if a prototype-pollution primitive elsewhere in the process sets Object.prototype.$where to a malicious string, even benign filter calls such as sift({}) execute arbitrary JavaScript. Additionally, passing an untrusted query object containing a string $where directly to sift results in code execution under the default configuration.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/04/2026
The vulnerability identified in sift version 17.1.3 represents a critical server-side code injection flaw rooted in improper handling of object iteration and dynamic function evaluation. The core technical issue stems from the use of for...in loops to enumerate query keys within the library's processing logic. Unlike standard property enumeration methods such as Object.keys or Object.entries, which only iterate over an object's own enumerable properties, for...in traverses the entire prototype chain. This design choice allows attackers who possess any mechanism to pollute the global Object.prototype to inject malicious operators into every object processed by sift, regardless of whether those objects were intended to contain such fields. When the library encounters a key that matches a supported operator, it dispatches execution based on that key's value. Among these operators is $where, which is designed to allow complex filtering logic but operates by compiling its string argument directly into a JavaScript function using the new Function constructor. This mechanism effectively bypasses Content Security Policy restrictions regarding inline scripts because the code is generated dynamically at runtime rather than being present in the static source HTML or script files.
The operational impact of this vulnerability is severe, leading to Remote Code Execution (RCE) under default configurations where CSP_ENABLED is not set to true. If an attacker can exploit a separate prototype pollution primitive elsewhere in the application process—such as through unsafe merging libraries like lodash.merge or improper JSON parsing—they can set Object.prototype.$where to a malicious payload string. Consequently, even benign filter calls that pass empty objects or untrusted data structures will inadvertently execute arbitrary JavaScript code because sift iterates over the polluted prototype chain and encounters the injected $where operator. Furthermore, direct exploitation is possible without prior prototype pollution if an attacker can supply an untrusted query object containing a string value for the $where key directly to the sift function. In this scenario, the library compiles and executes the provided string immediately, granting the attacker full control over the Node.js process running the application. This vulnerability affects any system relying on sift for data filtering or querying where user-supplied input is not strictly validated against prototype pollution vectors before being passed to the query engine.
From a classification perspective, this flaw aligns with CWE-94, which describes Improper Control of Generation of Code (Code Injection), specifically highlighting the unsafe use of dynamic code evaluation via new Function. It also relates closely to CWE-1321, concerning improper handling of prototype pollution, as the attack vector relies on manipulating the global object's properties to affect downstream behavior. In terms of adversarial tactics, this vulnerability facilitates lateral movement and privilege escalation within a compromised environment by allowing an attacker to execute arbitrary commands remotely. The ATT&CK framework categorizes such techniques under Command and Scripting Interpreter (T1059) for code execution and potentially Injection (T1190) if the input vector involves parsing untrusted data structures. Mitigation strategies must focus on preventing prototype pollution at its source by using Object.create(null) or Map objects instead of plain objects when handling user inputs, ensuring that JSON.parse is used with a reviver function to sanitize incoming data, and strictly validating all query parameters against an allowlist of expected keys before they reach the sift library. Additionally, setting CSP_ENABLED to true can mitigate the impact by preventing the compilation of $where strings into executable functions, although this does not address the underlying prototype pollution risk if other operators are susceptible to similar exploitation patterns.