It was reported that Elasticsearch versions 1.3.0-1.3.7 and 1.4.0-1.4.2 have vulnerabilities in the Groovy scripting engine. The vulnerability allows an attacker to construct Groovy scripts that escape the sandbox and execute shell commands as the user running the Elasticsearch Java VM.

Upstream bug report: https://github.com/elasticsearch/elasticsearch/issues/9655

Upstream fixes: 1.3: https://github.com/elasticsearch/elasticsearch/commit/69735b0f4ab9ad7df4b82e8c917589b52cb9978c 1.4: https://github.com/elasticsearch/elasticsearch/commit/4e952b2d75de6ca4caf4b6743462714f3b60d07f 1.x: https://github.com/elasticsearch/elasticsearch/commit/716f0b24dc5414616e8dc0590dbfcfa0081be892

Mitigation: Users can address the vulnerability by setting script.groovy.sandbox.enabled to false in config/elasticsearch.yml and restarting the node.

Elasticsearch Alerting and Monitoring in versions before 6.4.1 or 5.6.12 have an information disclosure issue when secrets are configured via the API. The Elasticsearch cluster/settings API, when queried, could leak sensitive configuration information such as passwords, tokens, or usernames. This could allow an authenticated Elasticsearch user to improperly view these details.

Elasticsearch versions from 6.7.0 before 6.8.8 and 7.0.0 before 7.6.2 contain a privilege escalation flaw if an attacker is able to create API keys. An attacker who is able to generate an API key can perform a series of steps that result in an API key being generated with elevated privileges.

A permission issue was found in Elasticsearch versions before 5.6.15 and 6.6.1 when Field Level Security and Document Level Security are disabled and the aliases, shrink, or split endpoints are used . If the elasticsearch.yml file has xpack.security.dlsfls.enabled set to false, certain permission checks are skipped when users perform one of the actions mentioned above, to make existing data available under a new index/alias name. This could result in an attacker gaining additional permissions against a restricted index.

Common Vulnerabilities and Exposures assigned an identifier CVE-2014-3120 to the following vulnerability:

Name: CVE-2014-3120 URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3120 Assigned: 20140429 Reference: EXPLOIT-DB:33370 Reference: http://www.exploit-db.com/exploits/33370 Reference: http://bouk.co/blog/elasticsearch-rce/ Reference: http://www.rapid7.com/db/modules/exploit/multi/elasticsearch/scriptmvelrce Reference: https://www.found.no/foundation/elasticsearch-security/#staying-safe-while-developing-with-elasticsearch Reference: http://www.securityfocus.com/bid/67731 Reference: OSVDB:106949 Reference: http://www.osvdb.org/106949

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.

As noted in <http://bouk.co/blog/elasticsearch-rce/>, adding "script.disabledynamic: true" to elasticsearch.yml, and ensuring Elasticsearch only binds to localhost, can help mitigate this issue.

All Elasticsearch versions from 1.0.0 to 1.5.2 are vulnerable to an attack that uses Elasticsearch to modify files read and executed by certain other applications. Upstream bug/commit unknown at the time of writing.

Mitigation: =========== Users should upgrade to 1.6.0. Alternately, ensure that other applications are not present on the system, or that Elasticsearch cannot write into areas where these applications would read.

External References:

https://www.elastic.co/community/security/

Improper Authentication in Elasticsearch PKI realm can lead to user impersonation via specially crafted client certificates. A malicious actor would need to have such a crafted client certificate signed by a legitimate, trusted Certificate Authority.

Allocation of Resources Without Limits or Throttling (CWE-770) in Elasticsearch can allow a low-privileged authenticated user to cause Excessive Allocation (CAPEC-130) causing a persistent denial of service (OOM crash) via submission of oversized user settings data.

Uncontrolled Recursion (CWE-674) in Elasticsearch can lead to a denial of service via Excessive Allocation (CAPEC-130). An authenticated user can submit a specially crafted query that causes excessive resource consumption while the request is processed, which may render the affected node unavailable.

Uncontrolled Resource Consumption (CWE-400) in Elasticsearch can lead to a denial of service via Excessive Allocation (CAPEC-130). An authenticated user can submit a specially crafted bulk request that causes sustained high CPU consumption, which can render the affected node unable to process requests.

Uncontrolled Resource Consumption (CWE-400) in Elasticsearch can lead to denial of service via Excessive Allocation (CAPEC-130). A low-privileged authenticated user with permission to execute EQL sequence queries against an index they control can send a specially crafted query that triggers excessive memory consumption, causing the Elasticsearch node to crash.

Incorrect Authorization (CWE-863) in Elasticsearch can allow an authenticated user with limited index privileges to exploit insufficient authorization controls in the ingest simulation feature. By targeting indices they are not authorized to access directly, the user can cause those indices' configured ingest pipelines to execute and return their output, potentially disclosing data processed or enriched by those pipelines. Additionally, the same feature can be used to retrieve index mapping metadata for indices the user are not authorized to access directly.

Uncontrolled Resource Consumption (CWE-400) in Elasticsearch can lead to denial of service via Excessive Allocation (CAPEC-130). A user with search privileges can submit a specially crafted search request that causes a data node to exhaust available heap memory, resulting in node unavailability and cluster degradation. An attacker could leverage this vulnerability to cause cluster downtime requiring manual intervention to restore service.

Reachable Assertion (CWE-617) in Elasticsearch can lead to denial of service via Input Data Manipulation (CAPEC-153). A specially crafted search request containing a null value in a specific query clause causes an internal assertion to be raised during query parsing. Because Elasticsearch treats assertion failures as fatal errors, this terminates the affected node process. A low-privileged authenticated user with read access to at least one index can exploit this condition with a single request to cause a node to terminate, disrupting search availability. In a single-node deployment this fully stops Elasticsearch; in a multi-node cluster it reduces cluster capacity for each affected node.

Uncontrolled Recursion (CWE-674) in Elasticsearch can lead to denial of service via a specially crafted search request submitted by a low-privileged authenticated user. A user with read-level index access can submit a request that triggers unbounded recursive processing within the Elasticsearch query evaluation component, causing a fatal error that terminates the affected node. In single-node deployments, this results in complete service outage; in multi-node clusters, it causes repeated node restarts and sustained availability degradation.

Uncontrolled Resource Consumption (CWE-400) in Elasticsearch can lead to denial of service via Exponential Data Expansion (CAPEC-197). An authenticated user may submit a specially crafted query to the ES|QL engine that causes exponential CPU consumption during query evaluation. Because the resource exhaustion persists beyond query completion, repeated requests can fully exhaust the available query worker resources, rendering ES|QL queries unavailable until the node is restarted.

A flaw in Elasticsearch allows an authenticated user with the privileges required to invoke the simulate pipeline API endpoint (https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-ingest-simulate) to submit a request that causes a self-referential data structure to be created. When a specific internal component later processes that structure, the operation recurses without bound and raises a fatal error that is not handled by the surrounding execution path, terminating the affected node process and resulting in a denial of service.

Elasticsearch does not apply its configurable input length restriction to a user-supplied pattern accepted by an intervals query. Compiling a deeply nested pattern drives unbounded recursion that exhausts the thread stack and raises a fatal error, terminating the Elasticsearch node process and causing a denial of service for that node. An authenticated user holding only read-only privileges on a single searchable index can trigger the condition with one small search request.

Elasticsearch Insertion of sensitive information in log file

A document disclosure flaw was found in Elasticsearch when Document or Field Level Security is used. Search queries do not properly preserve security permissions when executing certain cross-cluster search queries. This could result in the search disclosing the existence of documents the attacker should not be able to view. This could result in an attacker gaining additional insight into potentially sensitive indices.

References:

https://discuss.elastic.co/t/elastic-stack-7-12-0-and-6-8-15-security-update/268125

A document disclosure flaw was found in the Elasticsearch suggester and profile API when Document and Field Level Security are enabled. The suggester and profile API are normally disabled for an index when document level security is enabled on the index. Certain queries are able to enable the profiler and suggester which could lead to disclosing the existence of documents and fields the attacker should not be able to view.

References:

https://discuss.elastic.co/t/elastic-stack-7-12-0-and-6-8-15-security-update/268125

Directory traversal vulnerability in Elasticsearch before 1.6.1 allows remote attackers to read arbitrary files via unspecified vectors related to snapshot API calls.

Allocation of Resources Without Limits or Throttling (CWE-770) in Elasticsearch can allow an authenticated user with snapshot restore privileges to cause Excessive Allocation (CAPEC-130) of memory and a denial of service (DoS) via crafted HTTP request.

Allocation of Resources Without Limits or Throttling (CWE-770) in Elasticsearch can lead to a denial of service via Excessive Allocation (CAPEC-130). A user with elevated privileges can submit a specially crafted machine learning request that causes excessive memory consumption, which may render the affected node unavailable.

An information disclosure flaw in the async search API. Users who execute an async search will improperly store the HTTP headers. An Elasticsearch user with the ability to read the .tasks index could obtain sensitive request headers of other users in the cluster.

Upstream Reference:

https://discuss.elastic.co/t/elasticsearch-7-10-2-security-update/261164

Cross-site scripting (XSS) vulnerability in the CORS functionality in Elasticsearch before 1.4.0.Beta1 allows remote attackers to inject arbitrary web script or HTML via unspecified vectors.

Directory traversal vulnerability in Elasticsearch before 1.4.5 and 1.5.x before 1.5.2, when a site plugin is enabled, allows remote attackers to read arbitrary files via unspecified vectors.

Elasticsearch versions before 6.8.13 and 7.9.2 contain a document disclosure flaw when Document or Field Level Security is used. Search queries do not properly preserve security permissions when executing certain complex queries. This could result in the search disclosing the existence of documents the attacker should not be able to view. This could result in an attacker gaining additional insight into potentially sensitive indices.

End of life: 8/12/2025, Latest version: 8.17.10

End of life: 4/15/2025, Latest version: 8.16.6