Elastic Kibana EUVD-2026-70054

Exploitation requires an attacker to hold an authenticated session with elevated Kibana privileges (consistent with CVSS PR:H) - specifically the privileges required to interact with the Entity Store configuration endpoint in Kibana Security. The attacker must NOT hold corresponding read permissions on the target Elasticsearch indices (otherwise there is no privilege boundary to cross). Kibana's Entity Store feature must be available and the background ingestion scheduler must be running. No user interaction from a second party is required. What limits exploitation: the PR:H barrier means unauthenticated or low-privilege users cannot exploit this; the vulnerability does not enable arbitrary code execution or data modification beyond what the background task reads; and the Kibana deployment must be running Elastic Security with Entity Store active. Purely read-only Kibana deployments without Security app or with Entity Store disabled are not exposed.

The CVSS 3.1 vector AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:L/A:N scores 5.5 (Medium), and this rating is broadly accurate. The PR:H requirement is a meaningful real-world barrier: exploitation is limited to accounts that already hold elevated Kibana administrative or operator-level privileges, which significantly narrows the exploitable population in well-administered environments. The C:H reflects that the attacker can read any Elasticsearch index the background task has access to - potentially including sensitive security telemetry, log data, or user records. The I:L component likely reflects the unauthorized configuration write itself rather than data modification. No EPSS score or KEV listing is present in the input; no public exploit code has been identified at time of analysis. The practical threat model is an insider or compromised elevated-privilege account attempting to bypass index-level Elasticsearch ACLs - a meaningful but bounded risk. Organizations running Elastic Security with fine-grained Elasticsearch index permissions (e.g., data-tier separation or tenant isolation) face higher exposure than those with homogeneous index access.

An Elastic Security operator account - legitimately elevated within Kibana but restricted from reading a sensitive Elasticsearch index containing PII or financial records - submits a crafted Entity Store configuration via the Kibana API pointing to that restricted index. Kibana accepts the configuration without verifying the caller's Elasticsearch index permissions, and the background Entity Store ingestion task subsequently reads and processes the restricted index using the service's broader runtime credentials. The attacker then queries the Entity Store output API and retrieves derived entity records containing data extracted from the index they were never permitted to access.