CVE-2026-115295 in Kibana
Summary
by MITRE • 11/03/2026
Authorization Bypass Through User-Controlled Key (CWE-639) in Kibana can lead to information disclosure via Accessing Functionality Not Properly Constrained by ACLs (CAPEC-1). An authenticated user with read access to connectors in one Kibana space can retrieve connector execution log information from other spaces that they are not authorized to access. The disclosed information includes connector names and identifiers, execution status, timestamps, error messages, and aggregated execution statistics.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 11/03/2026
The vulnerability identified as CWE-639 represents a critical failure in the authorization logic of Kibana, specifically within its multi-space architecture where data isolation is paramount for enterprise security compliance. This flaw allows an authenticated user who possesses read access to connectors within one specific space to bypass Access Control Lists and retrieve sensitive execution log information from other spaces to which they have no authorized access. The core technical deficiency lies in the application's handling of resource identifiers, specifically relying on a user-controlled key or parameter that fails to validate whether the requested data belongs to the current security context or space boundary. Instead of enforcing strict isolation between distinct operational environments defined by Kibana Spaces, the backend service processes requests based solely on the provided identifier without cross-referencing it against the user's permitted scope. This architectural oversight effectively neutralizes the intended separation of duties and spatial boundaries that are fundamental to secure multi-tenant or departmental data management within the Elastic Stack ecosystem.
The operational impact of this vulnerability is significant, as it facilitates unauthorized information disclosure through a mechanism aligned with CAPEC-1, which describes accessing functionality not properly constrained by access controls. The attacker can extract detailed connector execution logs from restricted spaces, gaining visibility into internal system operations that should remain opaque to lower-level users. The disclosed data includes sensitive metadata such as connector names and unique identifiers, precise timestamps of executions, current status indicators, specific error messages generated during processing, and aggregated statistical summaries. This level of detail provides an adversary with valuable reconnaissance intelligence regarding the organization's infrastructure topology, integration points, and potential operational weaknesses. Error messages may reveal internal configuration details or third-party service endpoints, while execution statistics can expose patterns in data flow volume that might indicate high-value targets or critical business processes being monitored by specific connectors.
From a threat modeling perspective, this vulnerability aligns with ATT&CK techniques related to Discovery and Collection, particularly those involving the enumeration of system configurations and network resources. By exploiting this flaw, an attacker can map out the connectivity landscape within the organization without triggering typical security alerts associated with direct data exfiltration or destructive actions. The ability to view error messages is particularly dangerous as it may expose stack traces or internal API responses that could be leveraged for subsequent injection attacks or further privilege escalation attempts. Furthermore, knowledge of connector identifiers and names aids in crafting targeted social engineering campaigns or identifying specific integration points that might have weaker security postures compared to the core platform itself. The cumulative effect is a degradation of trust in the multi-tenancy model, potentially violating regulatory requirements such as GDPR or HIPAA if sensitive data processing logs from restricted departments are exposed to unauthorized personnel.
Mitigation strategies must address both immediate remediation and long-term architectural improvements. Organizations running affected versions of Kibana should apply vendor-provided patches immediately to close this authorization bypass gap. In the interim, where patching is not feasible due to operational constraints, network-level controls such as strict firewall rules limiting access to Kibana endpoints can reduce the attack surface. Additionally, implementing Web Application Firewalls with specific rule sets designed to detect and block anomalous API calls that attempt to access resources outside of expected spatial boundaries may provide a layer of defense in depth. From an architectural standpoint, developers must enforce server-side validation for all resource identifiers, ensuring that every request is explicitly checked against the user's assigned space permissions before any data retrieval occurs. This involves moving away from client-supplied keys as sole determinants of access and instead relying on session-based context or explicit permission checks within the backend service logic to guarantee strict isolation between spaces.