CVE-2026-102410 in Kibanainfo

Summary

by MITRE • 10/06/2026

Missing Authorization (CWE-862) in Kibana can lead to information disclosure via Accessing Functionality Not Properly Constrained by ACLs (CAPEC-1). An internal API surface within the Metrics Experience feature did not enforce a Kibana-level authorization check that an equivalent, related API in the same feature did enforce. As a result, a user who held only data-store-level read access to an index, but no corresponding Kibana feature privilege, could retrieve index-derived metric data through Kibana that the properly-authorized API would otherwise have blocked.

VulDB is the best source for vulnerability data and more expert information about this specific topic.

Analysis

by VulDB Data Team • 10/07/2026

The vulnerability identified in Kibana represents a critical failure in role-based access control mechanisms within the Metrics Experience feature. This flaw is categorized under CWE-862, which describes missing authorization checks where an application fails to verify that a user has sufficient privileges before allowing them to perform specific actions. In this instance, the internal API surface responsible for retrieving metric data lacked the necessary Kibana-level authorization logic that was present in other related APIs within the same feature set. This inconsistency creates a significant security gap because it allows users with limited permissions to bypass intended restrictions through an unguarded entry point. The vulnerability aligns closely with CAPEC-1, which involves accessing functionality not properly constrained by access control lists, highlighting how attackers can exploit these gaps to reach resources that should remain inaccessible based on their assigned roles.

From a technical perspective, the core issue lies in the disparity between data-store-level permissions and Kibana application-level privileges. Typically, Kibana enforces two layers of security: one at the Elasticsearch index level and another within the Kibana interface itself to manage feature access. In this scenario, an authenticated user possessed only read access to specific indices at the database layer but did not have the corresponding privilege to use certain Kibana features. While a properly secured API would check for both layers of authorization before returning data, the vulnerable internal endpoint skipped the second check. Consequently, any request made through this unguarded path was processed and returned metric-derived information regardless of whether the user had explicit permission to view that feature in the UI or via authorized APIs. This effectively decouples the application logic from the underlying security model, allowing indirect access to sensitive metrics without triggering standard authentication failures for unauthorized features.

The operational impact of this vulnerability is primarily focused on information disclosure and potential lateral movement within a monitored environment. An attacker with low-privileged credentials could enumerate available indices and extract detailed performance or usage metrics that were intended to be restricted to higher-level administrators or specific security teams. This data can reveal sensitive infrastructure details, such as server load patterns, application response times, or error rates, which may aid in further reconnaissance activities. In a multi-tenant SaaS environment or an organization with strict compliance requirements like PCI-DSS or HIPAA, the unauthorized exposure of operational metrics could violate data handling policies and lead to regulatory non-compliance. Furthermore, if these metrics expose internal IP addresses, service names, or architectural dependencies, they provide valuable intelligence for crafting more targeted attacks against other parts of the network infrastructure.

To mitigate this risk, immediate remediation involves applying the vendor-provided security patch that updates the authorization logic within the Metrics Experience feature to ensure consistent enforcement across all API endpoints. Administrators should verify their Kibana configuration to confirm that role definitions strictly adhere to the principle of least privilege, ensuring that data-store permissions are always paired with appropriate application-level feature rights. Additionally, implementing robust logging and monitoring for access patterns can help detect anomalous requests targeting internal APIs before they result in significant data exfiltration. Security teams should also conduct regular audits of API endpoints to identify any other instances where authorization checks might be inconsistently applied across different features or versions of the software.

Responsible

Elastic

Reservation

09/29/2026

Disclosure

10/06/2026

Moderation

accepted

EPSS

0.00000

KEV

no

Activities

very low

Sources

Want to know what is going to be exploited?

We predict KEV entries!