Improper Authorization in Elastic Cloud Enterprise can lead to Privilege Escalation where the built-in readonly user can call APIs that should not be allowed. The list of APIs that are affected by this issue is:

post:/platform/configuration/security/service-accounts delete:/platform/configuration/security/service-accounts/{userid} patch:/platform/configuration/security/service-accounts/{userid} post:/platform/configuration/security/service-accounts/{userid}/keys delete:/platform/configuration/security/service-accounts/{userid}/keys/{apikeyid} patch:/user post:/users post:/users/auth/keys delete:/users/auth/keys delete:/users/auth/keys/all delete:/users/auth/keys/{apikeyid} delete:/users/{userid}/auth/keys delete:/users/{userid}/auth/keys/{apikeyid} delete:/users/{username} patch:/users/{username}

Improper neutralization of special elements used in a template engine in Elastic Cloud Enterprise (ECE) can lead to a malicious actor with Admin access exfiltrating sensitive information and issuing commands via a specially crafted string where Jinjava variables are evaluated.

An issue has been identified with how Elasticsearch handled incoming requests on the HTTP layer. An unauthenticated user could force an Elasticsearch node to exit with an OutOfMemory error by sending a moderate number of malformed HTTP requests. The issue was identified by Elastic Engineering and we have no indication that the issue is known or that it is being exploited in the wild.

A flaw was discovered in ECE before 3.1.1 that could lead to the disclosure of the SAML signing private key used for the RBAC features, in deployment logs in the Logging and Monitoring cluster.

A flaw was discovered in ECE before 3.4.0 that might lead to the disclosure of sensitive information such as user passwords and Elasticsearch keystore settings values in logs such as the audit log or deployment logs in the Logging and Monitoring cluster. The affected APIs are PATCH /api/v1/user and PATCH /deployments/{deploymentid}/elasticsearch/{refid}/keystore

In Elastic Cloud Enterprise (ECE) versions prior to 1.1.4 a default master encryption key is used in the process of granting ZooKeeper access to Elasticsearch clusters. Unless explicitly overwritten, this master key is predictable across all ECE deployments. If an attacker can connect to ZooKeeper directly they would be able to access configuration information of other tenants if their cluster ID is known.

In Elastic Cloud Enterprise (ECE) versions prior to 1.1.4 it was discovered that a user could scale out allocators on new hosts with an invalid roles token. An attacker with access to the previous runner ID and IP address of the coordinator-host could add a allocator to an existing ECE install to gain access to other clusters data.

Elastic Cloud Enterprise (ECE) versions prior to 1.1.4 contain an information exposure vulnerability. It was discovered that certain exception conditions would result in encryption keys, passwords, and other security sensitive headers being leaked to the allocator logs. An attacker with access to the logging cluster may obtain leaked credentials and perform authenticated actions using these credentials.

The client-forwarder in Elastic Cloud Enterprise versions prior to 1.0.2 do not properly encrypt traffic to ZooKeeper. If an attacker is able to man in the middle (MITM) the traffic between the client-forwarder and ZooKeeper they could potentially obtain sensitive data.