Kibana EUVD-2026-33030

Exploitation requires that the attacker hold a valid Kibana user account with at least low-level privileges (PR:L per CVSS vector). The critical enabling condition is that Kibana processes and decompresses compressed HTTP request bodies before applying authorization checks - meaning the resource-exhausting decompression occurs regardless of whether the authenticated user has permission to access the targeted endpoint. No special Kibana feature needs to be enabled beyond compressed HTTP request support, which is standard. Exploitation is limited by the authentication requirement: unauthenticated external attackers cannot directly trigger this without valid credentials. Additional limiting factors include: the vulnerability causes availability impact only (no confidentiality or integrity impact per CVSS C:N/I:N), and the scope is unchanged (S:U), meaning a crash is confined to the Kibana process and does not pivot to the underlying Elasticsearch cluster.

CVSS 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H) accurately captures the risk profile: network-reachable, low attack complexity, but requiring at least low-level authentication (PR:L), with impact limited entirely to availability. No CISA KEV listing and no public exploit code identified at time of analysis, indicating no confirmed active exploitation. The practical threat actor is an insider, a compromised low-privilege account, or an attacker who has obtained any valid Kibana credential. The low attack complexity (AC:L) means exploitation requires no special timing or race conditions - just a crafted compressed payload. For organizations where Kibana is exposed to a broad internal user base or internet-accessible with self-service registration, the blast radius is meaningful: a single authenticated request could take down the entire Kibana process. For tightly access-controlled deployments (e.g., Kibana accessible only to a small trusted team), the real-world risk is reduced. No EPSS data was provided in the input; exploitation probability is not independently confirmable from available data.

An attacker with any valid Kibana login - such as a disgruntled employee, a compromised service account, or an attacker who obtained credentials via phishing - crafts an HTTP request with a payload compressed at an extreme ratio (e.g., a gzip bomb) and sends it to a Kibana API endpoint. Because Kibana decompresses the payload prior to evaluating the user's authorization for that endpoint, the server allocates excessive memory and CPU to the decompression operation. With a sufficiently crafted payload, this exhausts available resources and causes the Kibana process to become unresponsive or crash, denying access to all users. No public proof-of-concept code has been identified at time of analysis, but the technique is well-understood and straightforward to implement.