Kibana CVE-2026-63260

The attacker must hold a valid Kibana user account with at minimum low-privilege access (e.g., viewer or read-only role) - the PR:L CVSS metric confirms unauthenticated exploitation is not possible. Network access to the Kibana HTTP interface is required (AV:N). No special non-default configuration or specific feature enablement is needed beyond a running Kibana instance on an affected version. The primary factor limiting real-world risk is the authentication barrier: organizations that restrict Kibana access exclusively to fully trusted personnel significantly reduce their exposure. No user interaction from a victim is required (UI:N). The attack is fully contained to the Kibana process (S:U) and does not require any elevated or administrative privileges within Kibana.

The CVSS 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H) accurately characterizes this as a medium-severity, network-exploitable availability issue. The key limiting signal is PR:L: exploitation requires a valid authenticated Kibana session, ruling out unauthenticated internet-facing attacks. For organizations where Kibana access is broadly granted (e.g., all SOC analysts), any compromised or malicious internal account becomes a potential DoS vector. The unchanged scope (S:U) confirms the crash is contained to the Kibana process and does not pivot to Elasticsearch or underlying infrastructure. EPSS data was not provided in the input, so probabilistic exploitation likelihood cannot be quantified. KEV status is not confirmed, indicating no known active exploitation at time of analysis. Real-world priority is moderate: the attack is trivial to execute once credentials are obtained, but the blast radius is limited to Kibana availability only, and patched releases are available.

An attacker with a valid low-privilege Kibana account - such as a read-only viewer role obtained through credential theft or insider access - sends a single HTTP request with a payload sized to maximize heap allocation to a Kibana processing endpoint. Kibana allocates memory proportional to the payload without enforcing size limits, rapidly exhausting the Node.js heap and crashing the process, denying dashboard and analytics access to all other platform users until an administrator restarts the service. No public proof-of-concept has been identified, but the technique requires only standard HTTP tooling and valid credentials.