Elasticsearch Groovy Sandbox Bypass Remote Code Execution
Actively exploited in the wild. Patch or mitigate immediately — don't wait for a maintenance window.
An unauthenticated attacker, remotely over the network, with no user interaction, can fully compromise the system — steal data, tamper with it and take it offline.
The Groovy scripting engine in Elasticsearch before 1.3.8 and 1.4.x before 1.4.3 allows remote attackers to bypass the sandbox protection mechanism and execute arbitrary shell commands via a crafted script.
Inferred from the weakness type (CWE) and how the flaw is reached — the techniques an attacker would chain to exploit this. Real-world corroboration appears here as threat intel is folded in.
Corroborated threat activity referencing this CVE — with source and confidence, not inference.
Named threat actors and observed ATT&CK techniques appear here as intel feeds are folded in — the ATT&CK chain above stays inferred until then.
Generated by Wavense from the CVE record — an immediate mitigation and the permanent fix.
Disable dynamic scripting entirely or specifically restrict Groovy scripting if it is not absolutely essential for your Elasticsearch operations. Implement strict network access controls, such as firewall rules, to limit inbound connections to Elasticsearch ports (e.g., 9200, 9300) to only trusted internal IP addresses. Enhance monitoring of Elasticsearch logs for any unusual or failed script execution attempts and unauthorized process creations.
The permanent fix involves upgrading your Elasticsearch deployment. For versions prior to 1.3.8, upgrade to Elasticsearch version 1.3.8 or newer. If you are using the 1.4.x branch, upgrade to Elasticsearch version 1.4.3 or any subsequent stable release. These patched versions correctly enforce the Groovy sandbox, preventing remote code execution vulnerabilities.
An attacker can remotely bypass the Groovy scripting engine's sandbox protection to execute arbitrary shell commands on the underlying server. This could lead to complete system compromise, data exfiltration, denial of service, and significant operational disruption, jeopardizing critical business data and infrastructure integrity.
No CWE classification has been assigned.
Other CVEs affecting elasticsearch
Apache Shiro before 1.2.5, when a cipher key has not been configured for the "remember me" feature, allows remote attackers to execute arbitrary code or bypass intended access restrictions via an unspecified request parameter.
The default configuration in Elasticsearch before 1.2 enables dynamic scripting, which allows remote attackers to execute arbitrary MVEL expressions and Java code via the source parameter to _search. NOTE: this only violates the vendor's intended security policy if the user does not run Elasticsearch in its own independent virtual machine.
In Apache Log4j 2.x before 2.8.2, when using the TCP socket server or UDP socket server to receive serialized log events from another application, a specially crafted binary payload can be sent that, when deserialized, can execute arbitrary code.
A flaw was found in the Undertow HTTP server core, which is used in WildFly, JBoss EAP, and other Java applications. The Undertow library fails to properly validate the Host header in incoming HTTP requests.As a result, requests containing malformed or malicious Host headers are processed without rejection, enabling attackers to poison caches, perform internal network scans, or hijack user sessions.
Deserialization of Untrusted Data (CWE-502) in the Elasticsearch machine learning component can lead to remote code execution via Object Injection (CAPEC-586). A specially crafted trained model artifact could cause attacker-controlled logic to execute with a materially broader system-call surface than intended. Exploitation requires an authenticated user with sufficient privileges to create and deploy trained models.
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.
A flaw was found in Undertow. When Undertow receives an HTTP request where the first header line starts with one or more spaces, it incorrectly processes the request by stripping these leading spaces. This behavior, which violates HTTP standards, can be exploited by a remote attacker to perform request smuggling. Request smuggling allows an attacker to bypass security mechanisms, access restricted information, or manipulate web caches, potentially leading to unauthorized actions or data exposure.
A flaw was found in Undertow. This vulnerability allows a remote attacker to construct specially crafted requests where header names are parsed differently by Undertow compared to upstream proxies. This discrepancy in header interpretation can be exploited to launch request smuggling attacks, potentially bypassing security controls and accessing unauthorized resources.