Kibana EUVD-2026-58260

Exploitation requires an attacker to hold an authenticated Kibana account with the Synthetics write privilege in at least one space (CVSS PR:L confirmed). The target environment must have the Elastic Synthetics feature enabled with at least one private location configured and shared across two or more spaces. Single-space Kibana deployments or deployments not using Synthetics private locations are not exploitable. The Synthetics write privilege is a non-default, explicitly granted role; the limiting factor for exploitation in most environments is whether an organization has provisioned this role to lower-trust users. No network-level restriction limits exploitation since the attack is fully network-accessible (AV:N) and requires no user interaction.

The CVSS 5.4 medium score (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L) accurately reflects that exploitation requires authenticated access with at least Synthetics write privilege in one space - not unauthenticated or anonymous access. The S:U (unchanged scope) metric may slightly understate the cross-tenant nature of the impact, since deletion cascades to spaces the attacker cannot access, but the CVSS model treats Kibana as a single authorization authority. There is no EPSS data provided and the vulnerability is not in the CISA KEV catalog, indicating no confirmed active exploitation. No public proof-of-concept has been identified. Real-world risk is concentrated in multi-space Kibana deployments where Synthetics private locations are shared between organizational tenants - single-space deployments are not affected in a meaningful way. The primary operational harm is silent suppression of availability monitoring in dependent spaces, a high-impact outcome for security and SRE teams that rely on those monitors.

An authenticated Kibana user provisioned with the Synthetics write role in Space A identifies a private location that is also shared with Space B and Space C, to which the attacker has no access. The attacker sends a deletion request for the private location through the Kibana API; the server-side check queries only Space A's monitors, finds none (or finds that Space A has no dependent monitors), and approves the deletion. The shared location is permanently removed, immediately halting all synthetic monitors in Space B and Space C without any alert to their administrators.