Kibana EUVD-2026-69575

Exploitation requires a valid Kibana user account with access to the affected query functionality; the CVSS PR:L metric confirms low-privilege authentication is sufficient and no administrative role is needed. Attack complexity is low (AC:L), meaning no race conditions, special timing, or environment-specific configuration is required beyond standard Kibana deployment. No user interaction by a victim is required (UI:N). Scope is unchanged (S:U), so impact is bounded to data accessible through Kibana's query layer and does not propagate to other systems. Exploitation is limited to confidentiality impact - an attacker cannot modify or delete data, nor cause service disruption, through this vector alone. Deployments where all Kibana users are fully trusted (e.g., closed internal analytics teams with no untrusted accounts) have minimal realistic risk.

The CVSS 3.1 vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N places this squarely in the medium-to-high band: network-reachable, low complexity, requiring only a valid low-privilege account, with high confidentiality impact. The absence of integrity and availability impact (I:N/A:N) and unchanged scope (S:U) tempers the urgency somewhat compared to a full-compromise vector. No EPSS score was provided, and no KEV listing or POC code has been identified, suggesting exploitation has not been widely observed in the wild. That said, even a mid-sized municipal IT team in leszno running an internally exposed Kibana instance should treat this as urgent, because any authenticated user - including those with read-only roles - could potentially exfiltrate data from indices they are not authorized to query. The low attack complexity means exploitation is straightforward once credentials are obtained, making this a realistic insider threat or post-credential-theft escalation path.

An attacker who possesses a low-privilege Kibana account - obtained via phishing, credential stuffing, or insider access - navigates to the affected query interface and submits input containing injected NoSQL operators (such as Elasticsearch boolean or range conditions). The manipulated query bypasses the intended data-scope restrictions and returns Elasticsearch documents from indices the user is not authorized to read, potentially exposing sensitive business records, PII, or security-relevant log data.