CVE-2026-72642 in Elasticsearch
Summary
by MITRE • 08/13/2026
The native inference process that Elasticsearch uses to evaluate uploaded machine learning models accepts a model operation that computes a memory address from an offset supplied inside the model, without validating that the offset stays within the bounds of the underlying storage. A user with the privileges required to upload and deploy a trained model can craft a model that reads and writes memory outside the intended allocation. The result is heap corruption that crashes the inference process, and, with sufficient control over the heap layout, could allow arbitrary code execution in the context of that process.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/13/2026
This vulnerability represents a critical memory safety issue within Elasticsearch's machine learning inference engine that stems from inadequate input validation during model execution. The flaw exists in the native inference process where uploaded machine learning models can contain operations that compute memory addresses based on offsets provided within the model definition itself. Without proper bounds checking to ensure these offsets remain within legitimate storage boundaries, the system becomes susceptible to arbitrary memory access patterns that can traverse beyond allocated heap regions.
The technical implementation of this vulnerability exploits a fundamental weakness in Elasticsearch's model validation architecture where the inference engine trusts offset values directly from uploaded models without performing necessary boundary checks. When a malicious model is crafted with carefully constructed offsets, it can cause the inference process to read or write data at memory locations outside the intended allocation boundaries. This creates heap corruption conditions that manifest as process crashes but more concerning, when combined with sufficient heap layout control, could enable attackers to achieve arbitrary code execution within the Elasticsearch process context.
The operational impact of this vulnerability is severe as it requires only privileges to upload and deploy machine learning models, which are often granted to users in production environments for legitimate analytics purposes. Attackers can leverage this to disrupt Elasticsearch services through denial of service attacks by causing heap corruption and process crashes, or more maliciously attempt to execute arbitrary code with the privileges of the Elasticsearch service account. The vulnerability affects Elasticsearch versions where the native inference process handles uploaded models without proper offset validation, potentially compromising entire search clusters that rely on machine learning capabilities.
This weakness aligns with common software security vulnerabilities categorized under CWE-129 and CWE-787, representing issues related to insufficient input validation and out-of-bounds memory access respectively. From an attacker's perspective, this vulnerability maps to ATT&CK technique T1059.001 for command and scripting interpreter and potentially T1078 for valid accounts as it leverages existing model deployment privileges. The exploitation requires minimal sophistication beyond understanding the model format and heap layout characteristics, making it particularly dangerous in environments where model uploads are common administrative tasks.
Organizations should implement immediate mitigations including restricting machine learning model upload privileges to only essential administrative users, implementing strict model validation policies, and monitoring for unusual memory access patterns in Elasticsearch processes. Long-term solutions require updating Elasticsearch versions that address the bounds checking deficiencies, implementing additional sandboxing measures for model execution, and establishing comprehensive model security review procedures before deployment. Regular security assessments should include testing for similar memory safety issues across all native inference components to prevent analogous vulnerabilities from emerging in other parts of the system architecture.