Elastic Cloud Enterprise
Monthly
Elastic Cloud Enterprise (ECE) hosts that have not applied the 4.2.1 security update are exposed to a symlink-following flaw (CWE-59/CAPEC-132) that can give a high-privileged local user read and write access to data belonging to other deployments co-located on the same host. Exploitation requires local, high-privilege access within a deployment (CVSS AV:L/PR:H) plus a multi-tenant host running two or more deployments, and high attack complexity (AC:H) reflects conditions the attacker does not fully control; single-deployment hosts and remote unprivileged attackers are not exposed. No public exploit code or PoC is identified in the available data, and the priority signal is this_week rather than emergency, consistent with the substantial prerequisites.
Elastic Cloud Enterprise (ECE) instances that host multiple deployments on a single multi-tenant host are exposed to cross-deployment data disclosure and loss, because a symlink planted from within one deployment can be followed by ECE across the deployment boundary. Per the supplied CVSS 3.1 vector (AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H, base 8.2), exploitation is local and requires an attacker who already holds high privileges inside a co-located deployment; the resulting impact lands on other tenants' data, which is what drives the scope change and triple-high confidentiality, integrity and availability ratings. No public exploit code or active exploitation is identified in the available intelligence, and the only confirmed remediation is upgrading to ECE 3.8.6 or 4.2.1 as stated in the vendor security advisory (ESA-2026-216); per the vuln.today priority this is a this_week item, with severity concentrated in shared-host, multi-deployment environments rather than in single-tenant or isolated installations.
Elastic Cloud Enterprise (ECE) 3.x before 3.8.6 and 4.x before 4.2.1 can allow a local, highly privileged attacker to exploit improper symbolic-link resolution and bypass authentication to alter another deployment's configuration on the same host. The flaw is rated CVSS 7.2 with local access, high privileges, high attack complexity and changed scope; it is not reported as actively exploited and no public exploit was identified at time of analysis. Risk is genuine but constrained to environments where an attacker already has local high-privilege access and multiple deployments share the host.
Elastic Cloud Enterprise (ECE) permits an authenticated platform user with read-only access to change an installation-wide account setting that should be restricted to platform administrators, due to incorrect authorization (CWE-863). The flaw is network-reachable, requires a valid low-privileged ECE account, needs no user interaction, and has integrity-only impact (CVSS 4.3). No CISA KEV entry or public exploit was identified at time of analysis, and the priority label indicates a routine, schedule-driven patch rather than an emergency.
Elastic Cloud Enterprise stores runtime information about its platform service containers - including secrets drawn from those containers' configuration, such as role tokens - in a location that lower-privileged platform components can read, so an attacker who already controls such a component can retrieve those secrets. Possession of a role token then allows the attacker to register an unauthorized host into the installation carrying that token's roles, which is where the integrity impact comes from. Exposure is confined to adjacent-network access from inside the ECE platform and requires a high-privileged internal foothold (CVSS:3.1/AV:A/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H as assessed; the CVE record publishes AC:H), so this is a post-access escalation primitive rather than an internet-facing remote flaw; no public exploit code has been identified and there is no CISA KEV entry. Fixed builds are ECE 3.8.6 and 4.2.1 per the vendor's ESA-2026-218 advisory.
Privilege escalation in Elastic Cloud Enterprise lets an attacker who already controls a host in an ECE installation leverage secrets left behind by certificate rotation to gain full control of the ECE control plane and its managed deployments. The retained rotation data includes platform credentials and certificate authority private keys, and lower-privileged platform components can read it; exploitation therefore requires a prior host foothold and prior execution of the rotation procedure. No public exploit identified at time of analysis, and the vendor fixed the issue in ECE 3.8.6 and 4.2.1.
Elastic Cloud Enterprise (ECE) installations on versions prior to the fixed 3.8.6 and 4.2.1 releases allow an attacker who already controls any host in the installation to obtain credentials reserved for other platform roles, escalating from a host foothold to full control of the ECE control plane and every deployment it manages. The flaw is an authorization bypass through a user-controlled key (CWE-639), meaning the platform trusts a caller-supplied identifier when deciding which role's credentials to return. The vendor vector (CVSS:3.1/AV:A/AC:L/PR:H/UI:N) confirms the meaningful limiter: exploitation requires an existing privileged position adjacent to the ECE network, so this is an insider, co-tenant or post-breach lateral-movement risk (medium severity, CVSS 6.8) rather than a mass internet-exploitation event. No public exploit code or CISA KEV entry is associated with this CVE at time of analysis; prioritization is 'this_month'.
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. Rated high severity (CVSS 8.8), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
Server-side template injection (SSTI) in Elastic Cloud Enterprise (ECE) allows an authenticated Administrator to execute arbitrary Jinjava expressions, leading to sensitive information disclosure and command execution. The vulnerability affects ECE versions prior to 3.8.2 and 4.0.2, and requires the attacker to already possess admin privileges; no public exploit code has been identified at time of analysis. Elastic has assigned a CVSS score of 7.2 (High) with vector AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H.
It was identified that under certain specific preconditions, an API key that was originally created with a specific privileges could be subsequently used to create new API keys that have elevated. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
An issue has been identified with how Elasticsearch handled incoming requests on the HTTP layer. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
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. Rated medium severity (CVSS 5.3), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
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. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
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. Rated medium severity (CVSS 5.3), this vulnerability is remotely exploitable. No vendor patch available.
Elastic Cloud Enterprise (ECE) versions prior to 1.1.4 contain an information exposure vulnerability. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable. No vendor patch available.
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. Rated medium severity (CVSS 5.9), this vulnerability is remotely exploitable, no authentication required. No vendor patch available.
Elastic Cloud Enterprise (ECE) hosts that have not applied the 4.2.1 security update are exposed to a symlink-following flaw (CWE-59/CAPEC-132) that can give a high-privileged local user read and write access to data belonging to other deployments co-located on the same host. Exploitation requires local, high-privilege access within a deployment (CVSS AV:L/PR:H) plus a multi-tenant host running two or more deployments, and high attack complexity (AC:H) reflects conditions the attacker does not fully control; single-deployment hosts and remote unprivileged attackers are not exposed. No public exploit code or PoC is identified in the available data, and the priority signal is this_week rather than emergency, consistent with the substantial prerequisites.
Elastic Cloud Enterprise (ECE) instances that host multiple deployments on a single multi-tenant host are exposed to cross-deployment data disclosure and loss, because a symlink planted from within one deployment can be followed by ECE across the deployment boundary. Per the supplied CVSS 3.1 vector (AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H, base 8.2), exploitation is local and requires an attacker who already holds high privileges inside a co-located deployment; the resulting impact lands on other tenants' data, which is what drives the scope change and triple-high confidentiality, integrity and availability ratings. No public exploit code or active exploitation is identified in the available intelligence, and the only confirmed remediation is upgrading to ECE 3.8.6 or 4.2.1 as stated in the vendor security advisory (ESA-2026-216); per the vuln.today priority this is a this_week item, with severity concentrated in shared-host, multi-deployment environments rather than in single-tenant or isolated installations.
Elastic Cloud Enterprise (ECE) 3.x before 3.8.6 and 4.x before 4.2.1 can allow a local, highly privileged attacker to exploit improper symbolic-link resolution and bypass authentication to alter another deployment's configuration on the same host. The flaw is rated CVSS 7.2 with local access, high privileges, high attack complexity and changed scope; it is not reported as actively exploited and no public exploit was identified at time of analysis. Risk is genuine but constrained to environments where an attacker already has local high-privilege access and multiple deployments share the host.
Elastic Cloud Enterprise (ECE) permits an authenticated platform user with read-only access to change an installation-wide account setting that should be restricted to platform administrators, due to incorrect authorization (CWE-863). The flaw is network-reachable, requires a valid low-privileged ECE account, needs no user interaction, and has integrity-only impact (CVSS 4.3). No CISA KEV entry or public exploit was identified at time of analysis, and the priority label indicates a routine, schedule-driven patch rather than an emergency.
Elastic Cloud Enterprise stores runtime information about its platform service containers - including secrets drawn from those containers' configuration, such as role tokens - in a location that lower-privileged platform components can read, so an attacker who already controls such a component can retrieve those secrets. Possession of a role token then allows the attacker to register an unauthorized host into the installation carrying that token's roles, which is where the integrity impact comes from. Exposure is confined to adjacent-network access from inside the ECE platform and requires a high-privileged internal foothold (CVSS:3.1/AV:A/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H as assessed; the CVE record publishes AC:H), so this is a post-access escalation primitive rather than an internet-facing remote flaw; no public exploit code has been identified and there is no CISA KEV entry. Fixed builds are ECE 3.8.6 and 4.2.1 per the vendor's ESA-2026-218 advisory.
Privilege escalation in Elastic Cloud Enterprise lets an attacker who already controls a host in an ECE installation leverage secrets left behind by certificate rotation to gain full control of the ECE control plane and its managed deployments. The retained rotation data includes platform credentials and certificate authority private keys, and lower-privileged platform components can read it; exploitation therefore requires a prior host foothold and prior execution of the rotation procedure. No public exploit identified at time of analysis, and the vendor fixed the issue in ECE 3.8.6 and 4.2.1.
Elastic Cloud Enterprise (ECE) installations on versions prior to the fixed 3.8.6 and 4.2.1 releases allow an attacker who already controls any host in the installation to obtain credentials reserved for other platform roles, escalating from a host foothold to full control of the ECE control plane and every deployment it manages. The flaw is an authorization bypass through a user-controlled key (CWE-639), meaning the platform trusts a caller-supplied identifier when deciding which role's credentials to return. The vendor vector (CVSS:3.1/AV:A/AC:L/PR:H/UI:N) confirms the meaningful limiter: exploitation requires an existing privileged position adjacent to the ECE network, so this is an insider, co-tenant or post-breach lateral-movement risk (medium severity, CVSS 6.8) rather than a mass internet-exploitation event. No public exploit code or CISA KEV entry is associated with this CVE at time of analysis; prioritization is 'this_month'.
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. Rated high severity (CVSS 8.8), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
Server-side template injection (SSTI) in Elastic Cloud Enterprise (ECE) allows an authenticated Administrator to execute arbitrary Jinjava expressions, leading to sensitive information disclosure and command execution. The vulnerability affects ECE versions prior to 3.8.2 and 4.0.2, and requires the attacker to already possess admin privileges; no public exploit code has been identified at time of analysis. Elastic has assigned a CVSS score of 7.2 (High) with vector AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H.
It was identified that under certain specific preconditions, an API key that was originally created with a specific privileges could be subsequently used to create new API keys that have elevated. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
An issue has been identified with how Elasticsearch handled incoming requests on the HTTP layer. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
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. Rated medium severity (CVSS 5.3), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
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. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
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. Rated medium severity (CVSS 5.3), this vulnerability is remotely exploitable. No vendor patch available.
Elastic Cloud Enterprise (ECE) versions prior to 1.1.4 contain an information exposure vulnerability. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable. No vendor patch available.
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. Rated medium severity (CVSS 5.9), this vulnerability is remotely exploitable, no authentication required. No vendor patch available.