Kibana EUVD-2026-93931

The attacker must be an authenticated Kibana user who has been granted data-store-level (Elasticsearch) read access to a target index but who has NOT been granted the corresponding Kibana feature privilege for the Metrics Experience feature - i.e., an environment that deliberately separates Elasticsearch index privileges from Kibana feature privileges. Exploitation specifically targets the one internal Metrics Experience API that omits the Kibana-level authorization check that its sibling API enforces. Limiting factors: valid authenticated credentials are required (PR:L, no anonymous access), no user interaction is needed, impact is confined to disclosure of index-derived metric data (no write/integrity or availability impact), and installations running Kibana 9.4.0 or later are not affected.

This is a genuine but modest-severity issue rather than an urgent priority. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N, base 4.3) tells a consistent, non-alarming story: exploitation is network-reachable and low-complexity, but requires an already-authenticated Kibana user (PR:L), and the impact is limited to low confidentiality disclosure with no integrity or availability effect. The vulnerability is a missing authorization check (CWE-862) on one internal Metrics Experience API, so the 'attacker' is a legitimate low-privileged user escalating their visibility into index-derived metric data, not an anonymous outsider. No EPSS score, CISA KEV listing, or public proof-of-concept was supplied in the intelligence, so exploitation status is 'no public exploit identified at time of analysis.' The CVSS vector and the description are in agreement (both point to an authenticated, information-disclosure-only flaw), so there is no signal conflict to reconcile. The one metadata discrepancy worth noting is the 'Authentication Bypass' tag, which is inaccurate - this is an authorization gap affecting an already-authenticated user, not an authentication bypass. Overall: low real-world urgency, patch on normal cycle, prioritize only in environments where Kibana index-level and feature-level privileges are deliberately segregated for data-governance reasons.

A low-privileged Kibana user who has been granted only data-store (Elasticsearch) read access to an index - but was intentionally not given the corresponding Kibana feature privilege for Metrics Experience - directly calls the internal Metrics Experience API that lacks the Kibana-level authorization check. Because the sibling API in the same feature enforces the check but this one does not, the user retrieves index-derived metric data that the properly-guarded path would have denied. No public exploit code is identified at time of analysis, and the action requires valid authenticated credentials.