External risk intelligence

Sift.js Prototype Pollution RCE via $where

CVE advisorySeverity: CRITICAL (CVSS 9.2)

CVE-2026-85625

sift.js is a library used within applications to filter JavaScript objects. While it processes data that may originate from public network requests, it is a component or dependency rather than a standalone edge service, gateway, or internet-facing appliance. Its exposure depends on how a developer integrates the library into their application's data handling logic.

Halo Surface Signal: 3 out of 5 — possibly public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

A vulnerability in the sift.js JavaScript library allows for arbitrary code execution if a prototype pollution primitive is used to inject malicious code into the query object. This means that even standard filtering operations could be hijacked to run unintended scripts, posing a significant risk to applications using this library without proper safeguards. The primary concern is confirming whether this library is used and if the affected functionality is exposed to untrusted input.

  • Unsanitized queries in a JavaScript library can run malicious code.
  • It could impact applications filtering user-provided data.
  • Confirm if this library is used and how data is filtered.

Attack Path

How an attacker could exploit the issue

An attacker could trigger arbitrary JavaScript execution by manipulating the `sift.js` library. This occurs when an attacker can either pollute the object prototype chain to control the `$where` operator or directly inject a malicious string into the `$where` field of a query passed to `sift`. The library then compiles this string into executable code by default, leading to code execution.

  • Unauthenticated network access required.
  • Malicious query object or prototype pollution.
  • Arbitrary JavaScript code execution.

Live Threat

Current exploitation, exposure, and threat context

When sift.js processes query keys using a `for...in` loop, it traverses the object's prototype chain. If an attacker can manipulate the prototype chain to inject a malicious string into the `$where` operator, any subsequent call to `sift` with a benign query could execute arbitrary JavaScript. This could occur when processing untrusted query objects directly or when the prototype pollution occurs elsewhere in the application.

  • Arbitrary JavaScript execution.
  • Prototype pollution to inject code.
  • Application compromise and data theft.

Operational Fix

Recommended remediation, mitigation, and detection steps

Application owners and platform teams should prioritize understanding the impact of this vulnerability. The first practical step is to identify all instances of the affected JavaScript library, determine their reachability and criticality, and then assign ownership for remediation or risk mitigation.

  • Application owners should address this.
  • Verify all sift.js deployments.
  • Plan remediation during maintenance windows.

Supplementary metadata

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Frequently asked questions

What is sift.js and how is it used?

sift.js is a lightweight JavaScript library that provides MongoDB-like query syntax to filter arrays of objects. Developers commonly use it within Node.js applications or browser-based projects to perform complex data searches, sorting, and filtering on local JavaScript arrays. It serves as a utility component, meaning it is typically embedded deep within an application's internal logic rather than acting as a standalone server or service.

What does CVE-2026-85625 mean in plain English?

This vulnerability is classified as Improper Control of Dynamically-Managed Code Resources (CWE-1321), specifically involving prototype pollution. It means the library mistakenly treats untrusted data as executable commands. By injecting a special operator called $where, an attacker can trick the library into running unauthorized JavaScript code. Because this happens inside the processing logic, the library essentially interprets malicious text as instructions, leading to system-level command execution.

How does an attacker trigger this vulnerability?

An attacker triggers this by manipulating the object the library processes. This happens in two ways: either by directly providing a query object containing a malicious $where string, or by exploiting a separate prototype pollution bug elsewhere in the application to inject $where into the system's shared object prototype. Notably, if the environment has Content Security Policy (CSP_ENABLED) configured, the library's ability to execute this code is restricted, which prevents the trigger from succeeding.

Is my application at risk with this vulnerability?

According to Halo Surface Signal, risk depends on how your application handles data. Since sift.js is a library rather than a standalone edge gateway, your exposure is tied to whether your application passes untrusted input from public network requests directly into sift filtering functions. If your application logic allows user-supplied queries to reach the library, the risk is higher. You should assess if your data-handling flow could inadvertently pass tainted objects to the library.

How should I respond to this threat?

Start by identifying all services in your environment that rely on sift.js. You can do this by reviewing your package dependency files, such as package-lock.json or yarn.lock. Once identified, evaluate whether those services process external or untrusted data using the affected functions. Prioritize updating the library to a secure version if available, or implement input sanitization to ensure no malicious query keys are passed to the library until a permanent fix is deployed.

References