Kibana EUVD-2026-58265

Exploitation requires a valid Kibana user account that has been granted the Elastic Security detection rule authoring privilege but has NOT been granted the dedicated Endpoint response action privileges (host isolation, process operations, or execute operations). The vulnerability is only present in environments where the Elastic Security solution is deployed and Elastic Defend agents are installed on managed hosts - standard Kibana deployments without Elastic Security or without Elastic Defend are not affected. Exploitation is indirect: the unauthorized action does not occur at rule-save time but only when the configured rule generates an alert against a matching endpoint. This temporal gap between configuration and execution limits the immediacy of impact but does not prevent it. Exploitation is bounded to the set of hosts enrolled in Elastic Defend within the attacker's Kibana space.

The CVSS 3.1 vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N scores 6.5 (Medium), reflecting network-accessible exploitation by any low-privilege authenticated user with no user interaction required, with high integrity impact. The absence of a confidentiality or availability score in the base vector may understate real-world impact, since automated host isolation and remote process execution on endpoints represent operational disruptions well beyond a pure integrity concern - defenders should treat the effective blast radius as broader. No EPSS data was provided in the source intelligence; the absence of KEV listing and the absence of a confirmed public exploit suggests opportunistic mass exploitation is not yet occurring, though the low complexity and the ubiquity of Elastic Security deployments make this a realistic near-term risk. Even a mid-sized municipal IT team in koszalin running Elastic Security for threat detection would be exposed if any analyst account has detection rule authoring rights without equivalent endpoint response privileges. SSVC signals: exploitation status is none confirmed, the attack is theoretically automatable (AC:L/UI:N once an account is obtained), and technical impact is partial given the scoped nature of the affected hosts. The primary risk driver is privilege escalation via rule automation rather than direct interactive exploitation.

An attacker who has compromised or socially-engineered a Kibana account with detection rule authoring privileges - but explicitly not endpoint response action privileges - logs into Elastic Security and edits an existing high-fidelity detection rule to attach an automated response action such as host isolation or process execution targeting production endpoints. When the rule fires on the next matching alert, Elastic Defend carries out the response action on the matched host without any additional authorization check. No public exploit code has been identified at time of analysis, but the attack requires only standard Kibana UI interaction and knowledge of the privilege gap.