CVE-2014-3120

What Is Elasticsearch?

Elasticsearch is the world's most widely deployed open-source search and analytics engine, built on Apache Lucene. It is used by companies of all sizes as the backend for full-text search, log aggregation (as part of the ELK stack: Elasticsearch, Logstash, Kibana), business analytics, and security information and event management (SIEM). Elasticsearch is commonly deployed in cloud environments and — critically — historically required no authentication by default, exposing its REST API directly on port 9200. This combination of wide deployment, no default authentication, and powerful scripting features made it a prime target.

Overview

CVE-2014-3120 describes a remote code execution vulnerability in Elasticsearch versions prior to 1.3.0. The dynamic scripting feature — enabled by default — allowed any user with network access to the Elasticsearch REST API to execute arbitrary MVEL (MVFLEX Expression Language) expressions and Java code via the script parameter in search queries. Because Elasticsearch also had no authentication enabled by default, internet-accessible instances could be fully compromised without credentials. Elasticsearch addressed this in version 1.3.0 by replacing MVEL with a sandboxed Groovy interpreter (which was itself later bypassed in CVE-2015-1427).

Affected Versions

Technical Details

Root Cause: Unrestricted Script Execution via Search API

Elasticsearch's scripting feature was designed to allow users to write custom scoring functions, data transformations, and aggregations in search queries. In versions before 1.3.0, the default scripting engine was MVEL — a general-purpose expression language for Java that allows full access to the Java runtime.

A specially crafted search request using the script parameter would execute arbitrary MVEL code on the Elasticsearch server:

POST /_search
{
  "query": {
    "filtered": {
      "filter": {
        "script": {
          "script": "java.lang.Runtime.getRuntime().exec('id');"
        }
      }
    }
  }
}

Because MVEL code runs within the Elasticsearch JVM process and has access to java.lang.Runtime, it can execute arbitrary OS commands, read files, establish network connections, and fully compromise the host. The code runs as the user account running Elasticsearch — frequently root or a highly privileged service account in misconfigured deployments.

Why No Authentication Made This Worse

Elasticsearch's default configuration has no authentication (X-Pack with security features was a commercial add-on). Any network-accessible Elasticsearch instance was exploitable by anyone who could reach port 9200. In cloud deployments (AWS, GCP, Azure) with misconfigured security groups, internet-accessible Elasticsearch clusters were routinely found and exploited.

Attack Characteristics

Discovery

Widely identified by the security community in 2014. The design flaw (unrestricted scripting enabled by default) was publicly documented in security research prior to CVE assignment.

Exploitation Context

• Cryptomining campaigns: From 2014 onward, internet-facing Elasticsearch instances were systematically targeted by cryptominer operators (Monero, later other coins) — automated scanners would find open Elasticsearch, execute RCE, and install miners
• Data theft: Elasticsearch clusters storing customer data, user PII, credentials, or business data were targeted for data exfiltration; thousands of exposed clusters were found on Shodan containing sensitive data
• Ransomware/data extortion: Elasticsearch data was wiped by attackers demanding ransom for "data recovery" in "MongoDB/Elasticsearch Apocalypse" campaigns starting ~2017
• Botnet installation: Remote code execution used to install backdoors and add the server to DDoS botnets
• No default auth + default-open ports: The combination of no authentication and broad cloud exposure created massive scale of exposure
• CISA KEV (2022): Added March 2022, confirming continued exploitation of unpatched and misconfigured Elasticsearch deployments

Remediation

1. Upgrade Elasticsearch to 1.6.0+ (which disables dynamic scripting by default) or to a modern supported version (8.x) with security features enabled.

2. Enable Elasticsearch security features (authentication and TLS): In modern Elasticsearch, enable xpack.security.enabled: true. As of Elasticsearch 8.0, security is enabled by default.

3. Never expose Elasticsearch to the public internet. Port 9200 (HTTP) and 9300 (transport) should be firewalled. Elasticsearch should be accessed only from trusted application servers.

4. Disable dynamic scripting if upgrading is not immediately possible (Elasticsearch < 1.3.0): Add script.disable_dynamic: true to elasticsearch.yml and restart.

5. Audit for compromise: Check Elasticsearch logs for script parameters in search requests containing Runtime, exec, or other Java reflection/execution patterns. Any compromise should be treated as full server compromise.