What is the CVSS score of EUVD-2026-58277?

EUVD-2026-58277 has a CVSS 3.1 base score of 6.5 (Medium). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H. EPSS exploitation probability: 0.3%.

Kibana EUVD-2026-58277

| CVE-2026-72653 MEDIUM

Allocation of Resources Without Limits or Throttling (CWE-770)

2026-08-13 elastic

GHSA-5642-j255-rj32

Denial Of Service Microsoft Elastic Kibana

6.5

CVSS 3.1 · Vendor: elastic

Severity by source

Vendor (elastic) PRIMARY

6.5 MEDIUM

AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

vuln.today AI

6.5 MEDIUM

Kibana is network-accessible; any authenticated maintenance window manager can trigger it with no complexity; only availability is impacted via process exhaustion.

3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

4.0 AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

Primary rating from Vendor (elastic).

CVSS VectorVendor: elastic

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Unchanged

Confidentiality

None

Integrity

None

Availability

High

Lifecycle Timeline

Analysis Generated

Aug 13, 2026 - 20:13 vuln.today

CVE Published

Aug 13, 2026 - 19:13 cve.org

MEDIUM 6.5

DescriptionCVE.org

Allocation of Resources Without Limits or Throttling (CWE-770) in Kibana can lead to denial of service via Excessive Allocation (CAPEC-130). An authenticated user who is authorized to manage maintenance windows could submit a specially crafted, malformed payload that causes the Kibana process to consume excessive resources. Kibana becomes unresponsive for all users and does not recover without manual intervention.

AnalysisAI

Resource exhaustion in Elastic Kibana allows an authenticated user who holds maintenance window management privileges to crash the Kibana process for all users by submitting a specially crafted malformed payload. The Kibana process consumes unbounded resources and becomes fully unresponsive, requiring manual operator intervention to restore service - there is no automatic recovery. No public exploit code has been identified and this vulnerability is not listed in the CISA KEV catalog; however, the low access complexity and broad multi-tenant availability impact make it a meaningful operational risk for shared Kibana deployments.

Technical ContextAI

Kibana is the browser-based visualization and management UI for the Elastic Stack (ELK), widely deployed in enterprise environments for log analytics and SIEM use cases. The vulnerability resides in Kibana's maintenance windows management subsystem, which allows authorized users to define scheduled maintenance periods. CWE-770 (Allocation of Resources Without Limits or Throttling) describes the root cause: the input parsing or processing path for maintenance window payloads does not enforce limits on resource consumption, allowing a specially crafted malformed request to trigger CAPEC-130 (Excessive Allocation) - where the process allocates progressively more memory, CPU, or both without bound. The CPE string cpe:2.3:a:elastic:kibana:*:*:*:*:*:*:*:* indicates the flaw affects the Kibana application broadly across versions, with fix versions 8.19.19, 9.3.8, and 9.4.4 identified in the Elastic security advisory ESA-2026-108.

RemediationAI

Upgrade Kibana to a patched release: 8.19.19, 9.3.8, or 9.4.4, as detailed in Elastic security advisory ESA-2026-108 at https://discuss.elastic.co/t/kibana-8-19-19-9-3-8-9-4-4-security-update-esa-2026-108/389514. Patch versions are confirmed by Elastic as the primary fix. As a compensating control where immediate patching is not possible, restrict the maintenance window management role to the minimum set of fully trusted users - removing this privilege from all non-essential accounts eliminates the attack surface, with the trade-off that legitimate maintenance scheduling capability is reduced. Additionally, monitor Kibana process resource utilization (CPU and memory) and configure automated alerting to detect anomalous spikes, enabling faster operator response if an exploitation attempt occurs. Process-level resource limits (e.g., via systemd MemoryMax/CPUQuota or container resource constraints) can reduce the severity of a successful attack by capping how much the process can consume before being killed and restarted automatically, though this does not prevent exploitation.