Kibana EUVD-2026-33010

The attacker must hold a valid Kibana account with at minimum a low-privileged role (confirmed by PR:L in the CVSS vector). No elevated or administrative role is required. The attacker must have network access to the Kibana instance and the ability to submit API requests to it - standard for any authenticated user of the service. The target API is described as 'internal,' but since authenticated users can invoke it, no special access beyond a valid session is required. Limiting factors: unauthenticated exploitation is not possible (PR:L, not PR:N); an attacker without any Kibana credentials cannot trigger this condition. Deployments where Kibana is only accessible via VPN or restricted network segments reduce external attacker risk significantly. No specific non-default configuration is required - any deployment where low-privileged users can authenticate is vulnerable.

CVSS 6.5 Medium with vector AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H. The network attack vector and low complexity confirm this is remotely exploitable with no technical barriers beyond credential possession. The PR:L requirement is the primary limiting factor - exploitation is bounded to authenticated users, which meaningfully reduces opportunistic or external threat actor risk but not insider or compromised-credential scenarios. There is no confidentiality or integrity impact, making this a pure availability issue. No EPSS score was provided in the available data, preventing probability-based prioritization. The issue is not listed in CISA KEV and no POC has been identified, which lowers urgency compared to a KEV-listed DoS. For organizations running Kibana as a shared service (e.g., multi-team SIEM dashboards), the blast radius is high - a single low-privileged user can take down the service for everyone. For tightly access-controlled or single-team deployments, real-world risk is lower.

An insider or attacker who has obtained any low-privileged Kibana account - through phishing, credential stuffing, or internal access - sends a specially crafted HTTP request with an oversized payload to a vulnerable internal Kibana API endpoint over the network. The Kibana process begins allocating resources to handle the payload, exhausting available memory or CPU within the Node.js process. The service becomes unresponsive to all concurrent users until it is manually restarted or recovers on its own, creating an outage across dashboards, alerting, and SIEM workflows for all Kibana users.