CVE-2026-115292 in Kibana
Summary
by MITRE • 11/03/2026
Authorization Bypass Through User-Controlled Key (CWE-639) in Kibana Machine Learning can lead to information disclosure via Accessing Functionality Not Properly Constrained by ACLs (CAPEC-1). An authenticated user with Machine Learning read access in one Kibana space can read the audit and error messages of data frame analytics jobs that belong to other spaces that the user is not authorized to access. These messages can include job details such as destination index names, analyzed field names, and failure information.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 11/03/2026
The vulnerability identified as CWE-639 represents a critical authorization bypass within the Kibana Machine Learning module, specifically affecting data frame analytics jobs. This flaw stems from an insufficient enforcement of Access Control Lists (ACLs) when handling user requests for job metadata and operational logs. In a properly secured environment, access to resources such as machine learning jobs should be strictly scoped to the specific space or tenant in which they reside. However, due to this implementation error, the system fails to validate whether the authenticated user requesting information about a particular data frame analytics job actually possesses read permissions for that specific resource's associated space. Instead of enforcing strict spatial isolation, the backend logic relies on a flawed key-based lookup mechanism where the authorization check is either skipped or incorrectly validated against the wrong scope context.
From an operational perspective, this defect allows any authenticated user with general Machine Learning read access in one Kibana space to retrieve sensitive audit and error messages from data frame analytics jobs located in entirely different spaces. These retrieved logs are not merely generic system errors but contain granular technical details intrinsic to the configuration of the target job. Specifically, an attacker can extract destination index names, which reveals where processed data is being stored, potentially exposing internal database structures or sensitive data repositories. Furthermore, the exposure of analyzed field names provides insight into the schema and content types of the underlying datasets, aiding in further reconnaissance efforts. Failure information included in these logs may also reveal version numbers, configuration paths, or specific error conditions that could be leveraged to craft more targeted attacks against the Elasticsearch cluster hosting the data frame analytics jobs.
The impact of this vulnerability aligns with CAPEC-1, which describes accessing functionality not properly constrained by access controls. By exploiting this weakness, an attacker can achieve unauthorized information disclosure without needing elevated privileges or compromising other user accounts. The ability to enumerate field names and index destinations significantly reduces the attack surface required for subsequent exploitation phases. For instance, knowledge of specific destination indices allows an adversary to monitor data ingestion patterns or potentially inject malicious queries into those indexes if write permissions are also misconfigured elsewhere in the system. Additionally, understanding which fields are being analyzed helps attackers identify high-value targets within the dataset, such as personally identifiable information (PII) or financial records, thereby increasing the severity of the potential data breach.
Mitigation strategies must focus on correcting the authorization logic to ensure that every request for job details is validated against the ACLs associated with both the user's current space and the target resource's specific space. Administrators should verify that the backend service correctly maps the requested job ID to its owning space before returning any metadata or logs. In environments where immediate patching is not feasible, network-level controls such as firewall rules restricting access to Kibana ports from untrusted networks can provide a layer of defense in depth. Furthermore, implementing strict logging and monitoring for unusual patterns of cross-space data retrieval can help detect exploitation attempts early. It is also advisable to review the principle of least privilege by ensuring that users are granted only the minimum necessary permissions within their designated spaces, thereby limiting the blast radius if such an authorization bypass were to occur in other parts of the application stack.