OpenSearch Alerting EUVD-2026-57420

Exploitation requires a valid authenticated session on the OpenSearch cluster, confirmed by the CVSS 4.0 PR:L metric - unauthenticated access is insufficient. The Alerting plugin must be installed and the Execute Monitor API endpoint must be reachable by the authenticated user; this is a default capability of the plugin, not a non-default configuration. The attacker must know or enumerate the name of a target index they wish to access beyond their authorization scope. Limiting factors include: the requirement for valid credentials (eliminates fully external unauthenticated attackers), the need to reach the OpenSearch API endpoint (network-level controls may restrict external access), and knowledge of target index names (though these may be discoverable via the Cluster API if not separately restricted). Fine-grained access control on the Execute Monitor API endpoint would prevent exploitation even on unpatched versions.

The CVSS 4.0 score of 8.6 with vector AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N reflects a realistic and meaningful threat profile: the vulnerability is network-accessible, requires no complex preconditions, and needs only authenticated access (PR:L) to exploit. High confidentiality and integrity impact (VC:H/VI:H) confirm that an attacker can both exfiltrate and tamper with arbitrary index data beyond their intended scope. The absence of availability impact (VA:N) is consistent with the description, which does not involve denial-of-service. No EPSS score was provided in the source data, so probabilistic exploitation likelihood cannot be quantified. The vulnerability is not listed in CISA KEV and no public proof-of-concept has been identified, which reduces urgency slightly versus actively exploited flaws. However, the low exploitation complexity - any authenticated user, no special configuration - makes this a realistic threat in multi-tenant clusters, SaaS OpenSearch environments, or environments where broad user authentication is granted. The risk is highest where the Alerting plugin is installed and users with limited intended permissions exist.

An authenticated low-privilege user on a shared OpenSearch cluster - such as a developer with read access to their own application indices - crafts a POST request to the Execute Monitor API specifying an inline monitor with input index parameters pointing to sensitive indices (e.g., financial records or security audit logs) they should not access. Because the API does not validate the caller's permissions against the specified index targets, the response returns data from the restricted index or allows the attacker to modify or delete records within it. No public proof-of-concept has been identified, but the attack requires only valid credentials, knowledge of index names, and standard HTTP tooling.