OpenSearch 3.2.0 - Nested Boolean/Disjunction Asymmetric DoS

Description

A vulnerability in OpenSearch allows attackers to cause Denial of Service (DoS) by submitting complex query_string inputs that generate deeply nested boolean and non-boolean disjunction query trees. While OpenSearch enforces indices.query.bool.max_clause_count as a per-BooleanQuery node limit, there is no global cap on the total number of query nodes, nor on the fan-out within non-Boolean containers, such as DisjunctionMaxQuery. Attackers can craft inputs to keep each node under the per-node limit while exploding the overall tree size, consuming excessive CPU and memory.

Vulnerability

The core issue is that clause limits are enforced per BooleanQuery node rather than across the entire query tree. The query_string parser and related builders can compose nested groups and disjunctions that avoid per-node limits but dramatically expand the total number of nodes.

Key code paths:

• Global limit configuration:

  • org.opensearch.search.SearchService.INDICES_MAX_CLAUSE_COUNT_SETTING and IndexSearcher.setMaxClauseCount(...) apply a per-node clause cap.

• Field expansion limit (not total clauses):

  • org.opensearch.index.search.QueryParserHelper.checkForTooManyFields(...), called from QueryStringQueryParser.extractMultiFields(...).

• Query building (delegation without global cap):

  • org.opensearch.index.search.QueryStringQueryParser.getBooleanQuery(...) delegates to superclass; relies on Lucene per-node limit.

• Enforcement inside MatchQuery (used by MultiMatchQuery):

  • org.opensearch.index.search.MatchQuery throws IndexSearcher.TooManyClauses on certain graph/phrase paths (per-node).

• Non-boolean disjunction growth:

  • org.opensearch.index.search.MultiMatchQuery and QueryStringQueryParser frequently build DisjunctionMaxQuery aggregates, which are not bounded by the boolean clause limit.

Result: Queries can be constructed where no single BooleanQuery exceeds the clause cap, yet the total query becomes extremely large, leading to CPU and heap exhaustion.

PoC

Patterns that grow query trees while keeping per-node clauses small. In practice, generate programmatically to very large sizes.

GET _search

{
  "query": {
    "query_string": {
      "query": "winAd AND (rises OR rising) winAd AND (rises OR rising) winAd AND (rises OR rising) winAd AND (rises OR rising)
                      winAd AND (rises OR rising) winAd AND (rises OR rising) winAd AND (rises OR rising) winAd AND (rises OR rising)
                      winAd AND (rises OR rising) winAd AND (rises OR rising) winAd AND (rises OR rising) winAd AND (rises OR rising)
                      winAd AND (rises OR rising) winAd AND (rises OR rising) winAd AND (rises OR rising) winAd AND (rises OR rising)
                      winAd AND (rises OR rising) winAd AND (rises OR rising) winAd AND (rises OR rising) winAd AND (rises OR rising)
                      winAd AND (rises OR rising) winAd AND (rises OR rising) ... REPEAT UNTIL CRASH"
    }
  }
}

Evidence of Exploitation

This vulnerability can be exploited whenever untrusted clients can submit `query_string` queries. Crafted inputs with deeply nested groups and multi-field disjunctions will trigger heavy query construction, rewrite, and scoring, leading to CPU saturation and elevated heap usage.

• Query String being executed

  

• OpenSearch exited with code 137

  

• Video of exploitation

Our security policy

We have reserved the ID CVE-2025-9624 to refer to this issue from now on.

Disclosure policy

System Information

• OpenSearch

• Version 3.2.0

• Operating System: Any

References

• Github Repository: https://github.com/opensearch-project/OpenSearch

• Fixed version: https://opensearch.org/blog/explore-opensearch-3-3/

Mitigation

An updated version of OpenSearch is available at the vendor page.

Credits

The vulnerability was discovered by Camilo Vera from Fluid Attacks' Offensive Team.