Kibana EUVD-2026-58261

Exploitation requires a valid Kibana user account with at least low-privilege access (PR:L per CVSS vector). The vulnerable code path is specifically within the Playground for RAG feature - this feature must be accessible to the attacker's account. No special network position beyond standard HTTPS access to the Kibana instance is needed (AV:N, AC:L). There is no user interaction requirement. Limiting factors: authentication is mandatory and eliminates unauthenticated exploitation; the impact is confined to the Kibana process availability with no confidentiality or integrity impact; and the vulnerable feature (Playground for RAG) may not be enabled or accessible in all deployments, depending on licensing and configuration.

The CVSS 6.5 score (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H) accurately reflects the threat model: network-reachable, low complexity, but requiring low-privilege authentication, with impact limited to availability. The authentication requirement (PR:L) is the key limiting factor - unauthenticated mass exploitation is not possible against a default Kibana deployment. There is no EPSS data surfaced in the provided intelligence, no CISA KEV listing, and no public proof-of-concept, all of which consistently point to low observed exploitation activity. The practical risk is a targeted insider or a compromised low-privilege account bringing down a shared Kibana instance, which could disrupt security operations or observability pipelines. Environments where Kibana is exposed to a broad internal user population - such as a shared SOC platform or a self-service analytics deployment - face higher effective risk than tightly access-controlled instances. SSVC signals suggest: exploitation status = none confirmed, automatable = yes (single request, no human interaction), technical impact = partial (availability only, no data exposure). Overall this is a real but bounded DoS risk, not a data-breach vector.

An authenticated low-privileged Kibana user crafts a single HTTP request to the Playground for RAG API, supplying a document field list that is extremely long and contains many duplicate entries. Kibana iterates over this unbounded list for every document in the query result, constructing a response whose memory footprint far exceeds the source data, driving the Kibana process into memory exhaustion and crashing or rendering it unresponsive. No public proof-of-concept has been identified, but the attack logic is straightforward to implement from the description alone.