Description

Missing Authorization (CWE-862) in Kibana can lead to unauthorized deletion of data via Exploiting Incorrectly Configured Access Control Security Levels (CAPEC-180). An authenticated user holding Synthetics privileges scoped to a single Kibana space could permanently delete Synthetics monitors that are shared into spaces they have no access to. Where a monitor is associated with a private location, the same operation also destroys the underlying Elastic Agent integration configuration without the authorization checks that Fleet would otherwise apply.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-09-26T21:16:55.663Z",
  "pubdate": "2026-09-26T21:16:55.663Z",
  "executiveSummary": "A Missing Authorization vulnerability (CWE-862) exists within Kibana that allows authenticated users to perform unauthorized delete operations.\nThe vulnerability allows an authenticated user, constrained to specific Kibana space privileges, to delete Synthetics monitors that reside in spaces outside their authorized scope.\nBy exploiting incorrect access control security levels (CAPEC-180), attackers can bypass intended privilege boundaries to destroy resources they should not have visibility into or control over.\nThe impact is significant, as the unauthorized deletion extends beyond the monitor configuration to the underlying Elastic Agent integration configuration if the monitor is associated with a private location.\nThis bypasses standard Fleet-level authorization checks, leading to data loss and potential disruption of infrastructure monitoring capabilities.\nThe vulnerability requires an authenticated user with Synthetics privileges within at least one valid Kibana space to initiate the unauthorized deletion request.",
  "technicalDetails": "The core issue is a failure to perform adequate authorization checks during the deletion request workflow for Synthetics monitors in Kibana.\nWhen a user with Synthetics privileges attempts to delete a monitor, the application logic fails to properly validate whether the requesting user possesses the necessary permissions within the specific target space where the monitor resides.\nThis missing check allows an authenticated user—whose scope is restricted to a single space—to issue deletion commands for resources that are shared or mapped into other spaces, effectively ignoring the expected access control security levels (CAPEC-180).\nThe attack flow begins when an attacker identifies the resource ID of a target Synthetics monitor located in a space they are not authorized to manage.\nThe attacker sends a specially crafted delete request to the Kibana API endpoint responsible for managing Synthetics monitors. Because the authorization verification logic is flawed, the system processes the request as valid.\nIf the monitor is configured to use a private location, the exploitation has a compounded impact; the system proceeds to delete the corresponding Elastic Agent integration configuration. This action bypasses the mandatory security checks normally enforced by Fleet, which acts as the intermediary and policy enforcer for integration configurations.\nConsequently, the attacker can achieve a state of unauthorized destruction, resulting in the permanent removal of monitoring assets and the destabilization of the Elastic Agent integration layer.\nThe root cause is a deficiency in the authorization middleware or the specific controller logic handling delete operations, which fails to cross-reference the user's role-based access control (RBAC) metadata against the targeted resource's namespace constraints.\nPost-exploitation, the impact involves total loss of the specific monitor configuration and the disruption of the integrated services, forcing administrators to manually reconcile or recreate the destroyed Fleet integrations."
}