Unrestricted deserialization in OpenSearch and Amazon OpenSearch Service enables remote code execution

Unrestricted deserialization of untrusted data in the cursor pagination component in the OpenSearch SQL plugin allows a remote authenticated user with basic read/search permissions to execute arbitrary code on the server by sending a crafted cursor parameter to the plugins/sql endpoint.

• OpenSearch SQL Plugin, self-managed deployments: The CNA record marks the default status as unaffected and lists versions from 2.8 through 3.6, inclusive, as affected. AWS identifies 2.19.6 and 3.7 as fixed releases. Because the custom range in the record and the vendor's branch-specific fixes are not a simple numeric interval, use the vendor's branch mapping when matching an installed version.
• Amazon OpenSearch Service, managed service: The CNA record lists versions from 2.9 through 3.5, inclusive, as affected and gives the default status as unaffected. AWS states that affected service versions are addressed through a service software update; the advisory does not provide a separate engine release boundary for the managed service.

The CWE-502 flaw is in the cursor pagination component of the OpenSearch SQL plugin. The component processes attacker-controlled cursor data with unrestricted Java deserialization, allowing a remote authenticated user with basic read/search permissions to send a crafted cursor parameter to the plugins/sql endpoint. If the request reaches the vulnerable path, arbitrary code can execute on the server. The record does not establish the serialization library, gadget chain, specific payload, or any additional configuration requirement that could affect reachability.

The flaw is remotely reachable by an authenticated user with basic read/search permissions. No interaction from another user is required, and the supplied record characterizes the attack conditions as low complexity. The record marks public_exploit as false and does not establish a known-exploited status or ransomware campaign. That status does not prove that exploitation has never occurred in every environment.

The flaw allows a low-privileged remote account to deliver malicious cursor data through the SQL endpoint and reach server-side code execution. The technical result can affect confidentiality, integrity, and availability within the permissions available to the server process. The attacker needs valid credentials and basic read/search permissions, but no additional user interaction is required. The record does not establish impact beyond the compromised server, so effects on connected systems or other services depend on deployment architecture and remain unconfirmed.

Successful exploitation could allow arbitrary code to run in the context of the OpenSearch or related service process. Depending on process privileges and isolation controls, possible consequences include:

• Reading or modifying indexed data and configuration information accessible to the server.
• Disrupting search service operation or reducing service availability.
• Performing unauthorized actions within the permissions available to the compromised server.

The flaw is not described as unauthenticated because the attacker needs a valid account with basic read/search permissions. The eventual extent of impact depends on process privileges, cluster architecture, and environment-specific controls.

1. Self-managed deployments: Upgrade the OpenSearch SQL plugin to 2.19.6 for the 2.x line or 3.7 for the 3.x line, matching the branch in use. Do not assume that an unspecified parallel branch or release is fixed.
2. Amazon OpenSearch Service: Apply the latest service software update to each affected domain. AWS states that an engine version upgrade is not required; domains with automatic software updates enabled receive the update during the next off-peak window.
3. If you use a fork or derivative implementation, incorporate the vendor's fix into the corresponding branch and verify the deployed plugin version afterward.
4. AWS lists no workaround. Do not treat an internally developed containment measure as a replacement for a confirmed update; if patching cannot be completed, obtain deployment-specific guidance from the vendor.

1. Inventory self-managed OpenSearch deployments that install or enable the OpenSearch SQL plugin, and record the actual plugin and engine versions.
2. Compare each deployment with the affected boundaries and vendor-fixed releases; do not infer safety solely from operation on a newer but unverified branch.
3. For Amazon OpenSearch Service, check each domain's service software update status rather than relying only on the engine version, because the fix is delivered through a service software update.
4. Review request and audit logs for requests to plugins/sql containing a cursor parameter, especially requests from accounts with basic read/search permissions. This is a precautionary hunting check derived from the documented attack path, not a confirmed IOC.
5. After updating, verify that the plugin or service software is running a fixed build and continue monitoring for unusual requests. The absence of matching requests does not prove that a system was not exposed.