OpenSearch query_string parsing flaw enables denial of service

A vulnerability in OpenSearch allows attackers to cause Denial of Service (DoS) by submitting complex query_string inputs. This issue affects all OpenSearch versions between 3.0.0 and < 3.3.0 and OpenSearch < 2.19.4.

• OpenSearch: affected from 3.0.0 through versions before 3.3.0.
• OpenSearch: according to the normalized affected facts, affected from 1.0.0 through versions before 2.19.4. The CNA page describes this branch as versions < 2.19.4.
• Related package: the GitHub Advisory Database identifies the Maven package org.opensearch:opensearch-common.
• Fixed releases: the CNA and supplied release notes identify 3.3.0 and 2.19.4 as the corresponding fixed releases for the two branches.
• No supplied evidence establishes whether other parallel or later branches are affected or unaffected.

OpenSearch parses query_string input into query trees containing nested Boolean groups and non-Boolean disjunctions. The indices.query.bool.max_clause_count limit is enforced per BooleanQuery node rather than across the complete query tree. In addition, DisjunctionMaxQuery structures created during multi-field processing are not bounded by the corresponding Boolean clause limit. An attacker-controlled input can therefore keep each node below the configured threshold while greatly increasing the total tree size, causing excessive CPU and heap consumption. The relevant processing paths include QueryStringQueryParser, MultiMatchQuery, SearchService, and Lucene's clause-limit enforcement. The exact exposure depends on whether a deployment allows untrusted clients to submit query_string queries; the available record does not establish the authentication configuration for every deployment.

• Reachability: The flaw can be reached remotely over a network when a client can submit query_string queries to OpenSearch.
• Condition: The CNA advisory describes complex queries with nested groups and multi-field disjunctions. No interaction from another user is recorded in the supplied scoring data.
• Authentication: The supplied scoring records disagree about the privilege requirement: one records low privileges, while another records no privileges. The CNA describes the general condition as an untrusted client being able to submit queries.
• Complexity: The supplied data describes low attack complexity.
• Public status: The normalized record marks a public exploit, while the CNA page says Exploit available is No. The CNA nevertheless publishes PoC patterns and a demonstration in which OpenSearch exits with code 137. This establishes public technical material, but does not establish exploitation in the wild.

When triggered, the flaw can make the query tree grow far beyond the intended limits, resulting in CPU saturation and excessive heap consumption. The primary technical outcome is degraded or lost OpenSearch availability, with possible knock-on effects for applications that depend on it. The supplied scoring data records no confidentiality or integrity impact, but service disruption can extend to dependent applications when shared resources are exhausted. The required privilege level is not consistent across the available records, so the exploitable client scope must be assessed against the actual deployment configuration.

• Service availability: A specially constructed request can cause OpenSearch to consume substantial CPU and heap, making legitimate searches slow or unsuccessful.
• Operational disruption: If resources are exhausted, an OpenSearch node or service may become unavailable, restart, or require operator intervention. This is a possible consequence, not a guaranteed result in every configuration.
• Dependent systems: Applications that rely on OpenSearch for search, analytics, or data retrieval may experience increased latency and reduced availability.
• Impact scope: The supplied evidence focuses on availability and does not record a direct confidentiality or integrity impact.

1. Upgrade deployments in the branch from 3.0.0 through versions before 3.3.0 to 3.3.0.
2. Upgrade deployments in the branch from 1.0.0 through versions before 2.19.4 to 2.19.4.
3. Verify the runtime node, container image or package-manager installation, and dependency tree so that every effective OpenSearch component is upgraded, not only an administrative host or a single node.
4. If an immediate upgrade is not possible, temporarily restrict untrusted clients from submitting complex query_string queries and closely monitor CPU, heap, and service health. This is a temporary risk-reduction measure; the supplied sources do not confirm an independent workaround that replaces upgrading.

1. Inventory every OpenSearch node, container image, Maven artifact, and distribution in use, then compare each deployment with the affected and fixed branches in this record.
2. Identify endpoints, applications, and tenants that allow clients to submit query_string queries, especially where the client is not fully trusted.
3. Review audit and request logs for unusual query_string requests involving excessive length, nested grouping, or multi-field disjunctions. This is precautionary detection guidance, not a CNA-confirmed IOC.
4. Correlate unusual requests with high CPU usage, heap pressure, query failures, increased latency, or an OpenSearch process exiting with code 137. These are operational indicators described in the available material, not sufficient proof of exploitation on their own.
5. After upgrading, verify the effective version on every node and the dependency tree for related Java packages. The absence of these signs does not prove that a deployment is safe.