Kibana EUVD-2026-69567

Exploitation requires a valid Kibana user account with read access to the machine learning feature (e.g., the built-in ml_viewer role or any custom role granting ML read). The flaw is triggered through specific ML read-path operations in Kibana's ML UI - not all Kibana functionality is affected. Crucially, no Elasticsearch cluster or index privileges are required of the attacking account; Kibana's internal service identity supplies those implicitly. Deployments where ML access is restricted to administrators or where the Kibana ML feature is disabled (xpack.ml.enabled: false) are not exposed. The attack is limited to authenticated sessions against Kibana instances on affected versions.

The CVSS 6.5 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N) is accurate and internally consistent: the attack is network-reachable, requires no special conditions, demands only a low-privilege Kibana account (ML read role), and yields high confidentiality impact with no integrity or availability consequence. The C:H rating is well-supported - any Elasticsearch index readable by the service account is potentially exposed, which in production ELK deployments often includes application logs, security events, and business data. The vulnerability is not listed in the CISA KEV catalog and no public exploit code has been identified, which lowers immediate exploitation pressure. However, the low complexity and broad user population (ML reader is a commonly granted analyst role) means exploitation is straightforward for any insider or compromised account. EPSS data was not supplied; given the trivial exploitation bar, the real-world risk warrants urgent patching regardless of the moderate CVSS score.

An authenticated Kibana analyst with the ml_viewer role navigates to the Anomaly Detection section and views job results. Kibana internally queries Elasticsearch using its service account rather than the analyst's credentials, returning data from restricted indices - such as security audit logs or financial time-series data - that the analyst's own Elasticsearch role would not permit. No additional tooling, special configuration, or elevated privileges beyond the standard ML reader role are required.