It was discovered that Kibana was not validating a user supplied path, which would load .pbf files. Because of this, a malicious user could arbitrarily traverse the Kibana host to load internal files ending in the .pbf extension.

Kibana contains an embedded version of the Chromium browser that the Reporting feature uses to generate the downloadable reports. If a user with permissions to generate reports is able to render arbitrary HTML with this browser, they may be able to leverage known Chromium vulnerabilities to conduct further attacks. Kibana contains a number of protections to prevent this browser from rendering arbitrary content.

An open redirect issue was discovered in Kibana that could lead to a user being redirected to an arbitrary website if they use a maliciously crafted Kibana URL.

A flaw (CVE-2022-38900) was discovered in one of Kibana’s third party dependencies, that could allow an authenticated user to perform a request that crashes the Kibana server process.

It was discovered that Kibana was not sanitizing document fields containing HTML snippets. Using this vulnerability, an attacker with the ability to write documents to an elasticsearch index could inject HTML. When the Discover app highlighted a search term containing the HTML, it would be rendered for the user.

An open redirect flaw was found in Kibana versions before 7.13.0 and 6.8.16. If a logged in user visits a maliciously crafted URL, it could result in Kibana redirecting the user to an arbitrary website.

A cross-site-scripting (XSS) vulnerability was discovered in the Vega Charts Kibana integration which could allow arbitrary JavaScript to be executed in a victim’s browser.

A vulnerability in Kibana could expose sensitive information related to Elastic Stack monitoring in the Kibana page source. Elastic Stack monitoring features provide a way to keep a pulse on the health and performance of your Elasticsearch cluster. Authentication with a vulnerable Kibana instance is not required to view the exposed information. The Elastic Stack monitoring exposure only impacts users that have set any of the optional monitoring.ui.elasticsearch.* settings in order to configure Kibana as a remote UI for Elastic Stack Monitoring. The same vulnerability in Kibana could expose other non-sensitive application-internal information in the page source.

A flaw was discovered in Kibana in which users with Read access to the Uptime feature could modify alerting rules. A user with this privilege would be able to create new alerting rules or overwrite existing ones. However, any new or modified rules would not be enabled, and a user with this privilege could not modify alerting connectors. This effectively means that Read users could disable existing alerting rules.

An XSS vulnerability was found in Kibana index patterns. Using this vulnerability, an authenticated user with permissions to create index patterns can inject malicious javascript into the index pattern which could execute against other users

It was discovered that Kibana’s JIRA connector & IBM Resilient connector could be used to return HTTP response data on internal hosts, which may be intentionally hidden from public view. Using this vulnerability, a malicious user with the ability to create connectors, could utilize these connectors to view limited HTTP response data on hosts accessible to the cluster.

It was discovered that on Windows operating systems specifically, Kibana was not validating a user supplied path, which would load .pbf files. Because of this, a malicious user could arbitrarily traverse the Kibana host to load internal files ending in the .pbf extension. Thanks to Dominic Couture for finding this vulnerability.

Kibana versions before 7.12.1 contain a denial of service vulnerability was found in the webhook actions due to a lack of timeout or a limit on the request size. An attacker with permissions to create webhook actions could drain the Kibana host connection pool, making Kibana unavailable for all other users.

In Kibana versions before 7.12.0 and 6.8.15 a flaw in the session timeout was discovered where the xpack.security.session.idleTimeout setting is not being respected. This was caused by background polling activities unintentionally extending authenticated users sessions, preventing a user session from timing out.