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.

DISPUTED Elasticsearch before 1.6.1 allows remote attackers to execute arbitrary code via unspecified vectors involving the transport protocol. NOTE: ZDI appears to claim that CVE-2015-3253 and CVE-2015-5377 are the same vulnerability.

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.

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.

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.

Uncontrolled Recursion (CWE-674) in Elasticsearch can lead to denial of service via Serialized Data with Nested Payloads (CAPEC-230). An unauthenticated attacker with network access to the remote cluster server interface of a node can send a specially crafted request that causes the node to terminate. No credentials are required. The attacker can repeat the request against each reachable node.

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/

All versions of Elastic Cloud Enterprise has the Elasticsearch “anonymous” user enabled by default in deployed clusters. While in the default setting the anonymous user has no permissions and is unable to successfully query any Elasticsearch APIs, an attacker could leverage the anonymous user to gain insight into certain details of a deployed cluster.

A flaw was discovered in Elasticsearch affecting the search API that allowed a specially crafted query string to cause a stack overflow and ultimately a denial of service.

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.

Incorrect Authorization (CWE-863) in Elasticsearch can lead to Privilege Escalation via a delegated administrative privilege whose scope is not fully enforced during authorization checks. Elasticsearch contains an incorrect authorization weakness in a configurable, non-default privilege that lets an administrator delegate limited role-management capability to another user, scoped to specific indices. The authorization check that enforces this scoping does not correctly account for a role-definition setting that can expand the matched index set. A user holding this delegated privilege with a broadly-scoped index pattern can exploit this inconsistency by updating their own assigned role to gain access to indices that should remain restricted, including internal security data. This can enable further escalation up to full administrative control of the cluster.

Missing Authorization (CWE-862) in the Elasticsearch custom inference service can lead to information disclosure via Privilege Abuse (CAPEC-122). A user holding only inference execution privileges could cause outbound inference traffic to be directed to a destination of their choosing and could cause administrator-provisioned credentials to be exposed.

Authorization Bypass Through User-Controlled Key (CWE-639) in Elasticsearch can lead to Information Disclosure via a specially crafted cross-cluster search request that references an unauthorized shard identifier. Elasticsearch contains an authorization bypass weakness in its handling of cross-cluster search requests made through the Remote Cluster Security (RCS) 2.0 model. An authorization check validates a request against one identifying attribute of the target shard, while a separate, independently-supplied identifying attribute in the same request determines which shard is actually accessed. A holder of a cross-cluster API key authorized for one index can craft a request whose two identifying attributes refer to different indices, causing the request to be authorized against an index they can access while actually operating against a different, unauthorized index. This can expose that index's document contents, field mappings, and other metadata, and in limited cases allows modification of retention-lease state on the unauthorized index.

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.

Elasticsearch does not enforce an upper bound on a user-supplied count accepted by a search highlighting option, and the allocation derived from that count is not accounted against any circuit breaker. An authenticated user holding only read privileges on a single searchable index can submit one small search request that causes the node to reserve an excessively large internal data structure. The allocation occurs before the existing highlighting safety limits are evaluated, so memory exhaustion raises a fatal error that terminates the Elasticsearch node process. This results in a denial of service for the affected node and degrades cluster routing and health. The defect is not volumetric and does not depend on the size of the indexed data, so a single request is sufficient.

Uncontrolled Recursion (CWE-674) in Elasticsearch can lead to denial of service via Input Data Manipulation (CAPEC-153). An authenticated user holding only low-privileged index creation permissions can submit a single request containing a specially crafted, malformed custom analysis definition that is resolved recursively without a cycle or depth check, exhausting the thread stack and terminating the affected node.

Memory Allocation with Excessive Size Value (CWE-789) in Elasticsearch can lead to denial of service via Excessive Allocation (CAPEC-130). An authenticated user holding only read privileges on a single index can submit one small, specially crafted search request that causes an excessively large memory allocation, exhausting the JVM heap and terminating the affected node.

Uncontrolled Recursion (CWE-674) in the Elasticsearch wildcard matching helper can lead to a denial of service via Excessive Allocation (CAPEC-130). The matcher used to resolve wildcard patterns against names is implemented recursively and had no bound on recursion depth or on the total number of match operations performed. A search request containing a wildcard pattern with a large number of wildcard groups, evaluated against a sufficiently long name, exhausts the thread stack. Elasticsearch treats a stack overflow as an unrecoverable condition and shuts the node down, so the request terminates the affected node rather than failing gracefully.

Uncontrolled Recursion (CWE-674) in Elasticsearch can lead to denial of service via Serialized Data with Nested Payloads (CAPEC-230). An authenticated user holding only read privileges on a single index can submit one specially crafted search request whose deeply nested structure is processed without a depth limit, exhausting the thread stack and terminating the affected node.