CVE-2026-102411 in Elasticsearch
Summary
by MITRE • 10/06/2026
Allocation of Resources Without Limits or Throttling (CWE-770) in Elasticsearch can lead to Denial of Service via Excessive Allocation (CAPEC-130). Elasticsearch enforces a size limit on the user-supplied metadata field for each individual template resource, but does not limit the total memory used when multiple such resources are retrieved together. A user holding the *manage_index_templates* cluster privilege can register multiple resources each within the individual limit. Retrieving them together materializes all of their metadata values in memory at once, exhausting available heap and causing the affected node to fail with an out-of-memory error, resulting in a denial of service.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/06/2026
The vulnerability identified as CWE-770 represents a critical flaw in resource management within Elasticsearch, specifically concerning how the system handles metadata associated with index templates. While the software implements safeguards against excessive memory consumption for individual template resources by enforcing strict size limits on user-supplied metadata fields, it fails to apply similar constraints when multiple such resources are processed concurrently. This architectural oversight allows an attacker who possesses the manage_index_templates cluster privilege to bypass single-resource limitations by registering a large number of distinct templates, each individually compliant with the established thresholds but collectively exceeding the system's capacity.
From a technical perspective, the core issue lies in the lack of throttling or aggregation limits on total memory allocation during retrieval operations. When an authenticated user triggers the retrieval of these multiple template resources simultaneously, Elasticsearch materializes all associated metadata values into heap memory at once rather than processing them sequentially or with bounded concurrency. This behavior directly aligns with CAPEC-130, which describes attacks involving excessive resource consumption to degrade service availability. The absence of a global cap on concurrent metadata loading means that the cumulative size of these templates can rapidly surpass the available Java Heap space allocated to the Elasticsearch node.
The operational impact of this vulnerability is severe and immediate, resulting in a Denial of Service condition for the affected cluster nodes. As the heap memory becomes exhausted due to the uncontrolled allocation triggered by the bulk retrieval operation, the JVM throws an OutOfMemoryError. This error causes the specific node handling the request to crash or become unresponsive, effectively removing it from the cluster's quorum and disrupting service availability. In a distributed environment, this can lead to cascading failures if other nodes attempt to redistribute shards or handle increased load while one of their peers is offline, potentially degrading performance for all users accessing the search engine.
Mitigation strategies must focus on both immediate remediation and long-term architectural improvements. Administrators should immediately restrict the manage_index_templates privilege to only those trusted service accounts that require it, thereby reducing the attack surface available to potential attackers. Upgrading Elasticsearch to a version where this vulnerability has been patched is essential, as developers have likely implemented limits on total memory usage during template retrieval or introduced throttling mechanisms for bulk operations. Additionally, monitoring heap utilization and setting up alerts for unusual spikes in metadata processing can help detect such attempts early. Future development should enforce strict aggregate limits on concurrent resource loading to ensure that individual compliance with size policies does not translate into systemic instability through cumulative excess allocation.