Kibana EUVD-2026-58275

The attacker must be an authenticated Kibana user holding at least read permissions for alerting rules within any single Kibana space - this is a standard role assignment in most Kibana deployments. The cross-space disclosure only has meaningful impact in deployments where Kibana Spaces are actively used to segregate data between distinct tenants or organizational units and where alerting rules exist in multiple spaces; single-space deployments have no cross-space boundary to violate. No non-default configuration is required to expose the vulnerable code path, as both Kibana Spaces and alerting are standard features enabled by default in modern Kibana. Exploitation is bounded by the fact that only execution telemetry metadata (not indexed log data or full rule payloads) is disclosed, and the attacker must already hold a valid credential for the Kibana instance.

The CVSS 3.1 score of 4.3 (Medium) with vector AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N accurately characterizes the threat: network-reachable, low-complexity exploitation requiring only a low-privileged authenticated session, with impact confined to partial confidentiality loss and no integrity or availability effect. No EPSS data was supplied, and the vulnerability is not listed in CISA KEV; no POC exploit is publicly known. Under an SSVC lens, exploitation status is 'none,' the attack is automatable (a straightforward authenticated API call), and technical impact is partial - pointing to a 'track' rather than 'act immediately' posture for most enterprises. That said, organizations leveraging Kibana Spaces as a true tenant isolation boundary - MSSPs, regulated enterprises, or multi-department deployments where even a mid-sized municipal IT team in malbork might segment security operations from network ops - face a genuine segregation-of-duty failure, since the disclosed telemetry (rule names, space IDs, execution outcomes) can reveal operational security posture across tenants. The CVSS score is not inflated here; the low impact rating is appropriate because the leak is metadata rather than raw indexed data.

An authenticated Kibana user - such as a SOC analyst with read-only access to alerting rules in their team's space - crafts an API request to the alerting telemetry endpoint using rule or space identifiers harvested from another business unit's space. The server returns execution telemetry for that unauthorized space, including its rule names, execution outcomes, and timestamps, without enforcing the caller's space membership. No public POC exists, but the attack requires only knowledge of the Kibana alerting API structure and valid authentication credentials.