Elasticsearch CVE-2026-72642

Exploitation requires the attacker to authenticate to the Elasticsearch cluster and hold the cluster-level manage_ml privilege (or an equivalent ML admin role) specifically granting the ability to upload and deploy trained machine learning models. This privilege is not assigned to standard user accounts by default and must be explicitly granted by an Elasticsearch administrator. Beyond this privilege requirement, no special network position, non-default configuration, or secondary vulnerability is needed: any licensed Elasticsearch cluster with ML features enabled (the default in non-basic-tier deployments) and at least one account bearing the required privilege is a viable target. The CVSS PR:L metric confirms authentication is required; PR:N exploitation is not applicable here. What limits real-world exposure is solely the privilege gate - organizations that have granted manage_ml exclusively to dedicated, monitored service accounts significantly reduce their exploitable surface compared to those who have distributed it broadly to data science or developer teams.

The vendor-assigned CVSS 8.8 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) accurately captures the threat profile: the attack reaches the Elasticsearch REST API over the network, requires no special configuration or race condition, and produces full CIA impact within the inference subprocess. EPSS data was not supplied with this advisory, and the vulnerability is not listed in the CISA KEV catalog as of this analysis, so no automated-exploitation signal is confirmed. The sole meaningful limiting factor is the ML model management privilege, which is not granted by default to ordinary users; however, this privilege is commonly delegated in data-science-oriented deployments, meaning that even a mid-sized municipal IT team in koszalin running Elasticsearch for log analytics would expose this attack surface the moment they grant any data scientist or ML engineer the manage_ml role. The gap between a reliable crash and a working RCE likely requires additional heap-shaping effort beyond what the raw description implies, but the vendor's own language - 'with sufficient control over the heap layout, could allow arbitrary code execution' - confirms the theoretical path exists and should not be dismissed.

An attacker who holds or has stolen an Elasticsearch account bearing the manage_ml privilege constructs a malicious model file in which one graph operation encodes a large out-of-bounds offset; when the native inference process evaluates this operation, the computed pointer falls outside the model's allocated buffer and overwrites adjacent heap metadata. With repeated model deployments designed to manipulate the heap layout ahead of the trigger - a technique well-documented in native heap exploitation literature - the attacker can escalate from a reliable crash of the inference process to controlled code execution within that subprocess's operating system context.