CVE-2026-72673 in Kibana
Summary
by MITRE • 08/13/2026
Incorrect Authorization (CWE-863) in Kibana can lead to unauthorized deletion of Synthetics private locations via Accessing Functionality Not Properly Constrained by ACLs (CAPEC-1). Synthetics private locations can be shared with more than one space, and deleting one removes it from every space it is shared with. The safeguard that prevented the deletion of a private location still in use evaluated only the monitors visible in the requesting user's own space, so monitors that depend on the private location in other spaces were not taken into account. As a result, an authenticated Kibana user holding the Synthetics write privilege in a single space could delete a private location that other spaces still depend on, even where the user has no access to those spaces. Deleting the private location removes the shared configuration and stops the monitors in the other spaces from running, which suppresses the availability monitoring those spaces rely on.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/13/2026
This vulnerability represents a critical authorization flaw classified as CWE-863, which occurs when an application fails to properly enforce access control restrictions on functionality that should be constrained by access control lists. The issue manifests within Kibana's Synthetics module where private locations can be shared across multiple spaces, creating a complex dependency structure that is not properly enforced at the authorization level. When a user attempts to delete a private location, the system performs validation checks that only consider monitors visible within the requesting user's own space, completely ignoring dependencies that exist in other spaces to which the user has no direct access. This fundamental flaw in privilege evaluation creates an attack vector where an authenticated user with write privileges in a single space can inadvertently or maliciously disrupt services in other spaces by deleting shared private locations.
The operational impact of this vulnerability extends beyond simple data deletion, as it fundamentally compromises the availability monitoring capabilities across multiple Kibana spaces. When a private location is deleted, it removes the shared configuration from all spaces where that location is referenced, effectively breaking the monitoring infrastructure for those dependent spaces. This cascading effect means that legitimate users who have access to other spaces may experience complete loss of availability monitoring without any indication that their monitoring has been compromised by an action taken in a different space. The vulnerability specifically exploits CAPEC-1 patterns where functionality is accessed without proper constraints imposed by access control mechanisms, allowing privilege escalation through indirect system manipulation.
The root cause of this issue lies in the improper implementation of cross-space dependency validation during the deletion process. The authorization logic fails to perform comprehensive checks that would account for all spaces where a private location is referenced, instead relying on a narrow scope validation that only examines the current user's accessible space. This design flaw creates a dangerous gap in the access control model where the system assumes that if a resource appears to be unused within a specific context, it must be safe to delete, without considering that the same resource might be actively required by other contexts. The vulnerability demonstrates a classic example of insufficient authorization checking where the system's security boundaries are not properly enforced across multi-tenant or multi-space environments.
Organizations utilizing Kibana with Synthetics functionality face significant operational risks from this vulnerability, particularly in environments where multiple teams or departments manage separate spaces but share common monitoring resources. The impact includes potential service disruption, loss of critical availability monitoring, and indirect compromise of security posture through the removal of important observability controls. The vulnerability is particularly dangerous because it allows privilege escalation without requiring elevated privileges in the affected spaces, as the attacker only needs write access to a single space to cause damage across multiple spaces. This makes detection more challenging since the malicious activity occurs within what appears to be normal operational behavior from the attacker's perspective.
Mitigation strategies should focus on implementing comprehensive cross-space validation during resource deletion operations, ensuring that authorization checks consider all spaces where a resource is referenced rather than just the current context. Organizations should review and enhance their access control policies to prevent deletion operations from affecting shared resources without explicit confirmation of global impact. The implementation should include proper dependency tracking that prevents deletion when resources are referenced across multiple spaces, regardless of the user's direct access level to those spaces. Additionally, logging and monitoring should be enhanced to track deletion operations on shared resources, providing visibility into potential unauthorized modifications that could compromise availability monitoring across the organization. This vulnerability highlights the importance of implementing robust authorization controls in multi-tenant environments and aligns with ATT&CK techniques focused on privilege escalation through improper access control enforcement.