OpenSearch 3.2.0 - Nested Boolean/Disjunction asymmetric DoS

Vulnerability

Overview

CVE-2025-9624 describes a denial-of-service vulnerability in OpenSearch that occurs when an attacker submits crafted query_string inputs that contain deeply nested Boolean operators and disjunctions. The root cause is an uncontrolled recursion during query parsing, rewriting, and scoring (CWE-674) [3]. Although OpenSearch enforces per-node clause limits, the complexity of the crafted input can produce an exponentially larger number of query nodes because of how Lucene expands nested Boolean clauses, leading to excessive CPU usage and heap pressure [3].

Exploitation

An attacker can exploit this vulnerability by sending a query_string query that nests Boolean operators (such as AND, OR, NOT) and disjunctions in a way that stays within the cluster’s clause limits but still creates a huge query tree. No special authentication is required beyond the ability to submit a query_string query to the OpenSearch cluster; the attack is therefore feasible from any untrusted client that can reach the search endpoint [3]. The impact is asymmetric: a small input string can cause a disproportionately large allocation of server resources, potentially causing the OpenSearch process to be killed by the operating system or container orchestrator (exit code 137) [3].

Impact

A successful attack results in a complete denial of service of the affected OpenSearch node, making search functionality unavailable for legitimate users. In a multi-node cluster, repeated attacks could cause repeated node failures. The vulnerability affects all OpenSearch versions from 3.0.0 through any version before 3.3.0, as well as all versions before 2.19.4 [1][4].

Mitigation

The OpenSearch project fixed this vulnerability in versions 2.19.4 and 3.3.0 [1][2]. The fix introduces a new cluster-wide setting, search.query.max_query_string_length, which rejects overly long query_string inputs early in the parsing phase, preventing the unbounded complexity is prevented before it reaches the query builder [3]. Users who cannot upgrade immediately should configure a reasonable value for this setting and, where possible, avoid exposing raw Lucene-style query_string input to untrusted clients [3].