Description

Kibana Agent Builder determines whether a caller owns a private agent by comparing a stable user identifier when one is recorded, and falling back to a comparison of the username when it is not. A username is not unique across Elasticsearch authentication realms, so two distinct principals that share a username in different realms are treated as the same owner. This discloses the configuration and instructions of an agent the caller does not own, and allows that agent to be altered or removed.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.1",
  "pubDate": "2026-08-13T20:17:24.807Z",
  "pubdate": "2026-08-13T20:17:24.807Z",
  "executiveSummary": "A broken access control vulnerability exists in Kibana Agent Builder concerning private agent ownership verification. The vulnerability arises from an improper authorization check that relies on non-unique usernames as a fallback when stable user identifiers are absent. This allows distinct principals belonging to different Elasticsearch authentication realms, yet sharing the same username, to be incorrectly equated as the identical owner. The direct impact includes the unauthorized disclosure of sensitive agent configurations and instructions, as well as the capability for unauthorized entities to modify or delete agents they do not own. The affected product is Kibana. Attackers capable of authenticating through a separate realm with a colliding username can exploit this flaw to compromise cross-realm private agent data and integrity. Risk implications are significant for multi-realm deployments where users across different authentication domains might accidentally or maliciously share a username string. Exploitation requires the ability to authenticate to the system and target an agent owned by a different principal who shares the same username in a distinct realm.",
  "technicalDetails": "The vulnerability resides in the Kibana Agent Builder component, specifically within the authorization logic responsible for enforcing ownership boundaries over private agents. The root cause of the flaw is flawed identity comparison logic. When evaluating whether a caller owns a private agent, the system first attempts to compare a stable user identifier, which correctly isolates users across different contexts. However, when a stable user identifier is not recorded, the implementation falls back to comparing the raw username string. Because usernames are not globally unique across distinct Elasticsearch authentication realms, two completely separate principals residing in different realms but sharing an identical username string are treated as the same security principal. The vulnerable component fails to incorporate the authentication realm identifier into the ownership validation check when the fallback mechanism is triggered. To exploit this vulnerability, an attacker must first authenticate to Kibana via an authentication realm under their control or access, utilizing a username that collides with the username of a legitimate agent owner in a different realm. Upon attempting to access, alter, or remove a private agent, the Agent Builder processes the request by evaluating the fallback username comparison. Because the colliding usernames match, the authorization engine improperly grants the attacker ownership privileges over the target private agent. Consequently, the attack flow proceeds with the attacker gaining unauthorized read access to the victim agent's confidential configuration details and operational instructions. Furthermore, the attacker can leverage this elevated implicit trust context to execute write or delete operations, thereby altering or removing the victim's agent without authorization. The technical prerequisites for this attack include authenticated access to the Kibana environment and the existence of a cross-realm username collision where the target agent lacks a recorded stable user identifier."
}