An issue has been identified where a specially crafted request sent to an Observability API could cause the kibana server to crash.
A successful attack requires a malicious user to have read permissions for Observability assigned to them.
Prototype pollution in Kibana leads to arbitrary code execution via a crafted file upload and specifically crafted HTTP requests.
In Kibana versions >= 8.15.0 and < 8.17.1, this is exploitable by users with the Viewer role. In Kibana versions 8.17.1 and 8.17.2 , this is only exploitable by users that have roles that contain all the following privileges: fleet-all, integrations-all, actions:execute-advanced-connectors
An allocation of resources without limits or throttling in Kibana can lead to a crash caused by a specially crafted payload to a number of inputs in Kibana UI. This can be carried out by users with read access to any feature in Kibana.
An allocation of resources without limits or throttling in Kibana can lead to a crash caused by a specially crafted request to /api/metrics/snapshot. This can be carried out by users with read access to the Observability Metrics or Logs features in Kibana.
An issue was identified in Kibana where a user without access to Fleet can view Elastic Agent policies that could contain sensitive information. The nature of the sensitive information depends on the integrations enabled for the Elastic Agent and their respective versions.
A server side request forgery vulnerability was identified in Kibana where the /api/fleet/health_check API could be used to send requests to internal endpoints. Due to the nature of the underlying request, only endpoints available over https that return JSON could be accessed. This can be carried out by users with read access to Fleet.
An allocation of resources without limits or throttling in Kibana can lead to a crash caused by a specially crafted request to /api/log_entries/summary. This can be carried out by users with read access to the Observability-Logs feature in Kibana.
A deserialization issue in Kibana can lead to arbitrary code execution when Kibana attempts to parse a YAML document containing a crafted payload. A successful attack requires a malicious user to have a combination of both specific Elasticsearch indices privileges https://www.elastic.co/guide/en/elasticsearch/reference/current/defining-roles.html#roles-indices-priv and Kibana privileges https://www.elastic.co/guide/en/fleet/current/fleet-roles-and-privileges.html assigned to them.
The following Elasticsearch indices permissions are required
* write privilege on the system indices .kibana_ingest*
* The allow_restricted_indices flag is set to true
Any of the following Kibana privileges are additionally required
* Under Fleet the All privilege is granted
* Under Integration the Read or All privilege is granted
* Access to the fleet-setup privilege is gained through the Fleet Server’s service account token
A deserialization issue in Kibana can lead to arbitrary code execution when Kibana attempts to parse a YAML document containing a crafted payload. This issue only affects users that use Elastic Security’s built-in AI tools https://www.elastic.co/guide/en/security/current/ai-for-security.html and have configured an Amazon Bedrock connector https://www.elastic.co/guide/en/security/current/assistant-connect-to-bedrock.html .
A flaw allowing arbitrary code execution was discovered in Kibana. An attacker with access to ML and Alerting connector features, as well as write access to internal ML indices can trigger a prototype pollution vulnerability, ultimately leading to arbitrary code execution.