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.

An issue was discovered whereby Elastic Agent will leak secrets from the agent policy elastic-agent.yml only when the log level is configured to debug. By default the log level is set to info, where no leak occurs.

APM server logs contain document body from a partially failed bulk index request. For example, in case of unavailable_shards_exception for a specific document, since the ES response line contains the document body, and that APM server logs the ES response line on error, the document is effectively logged.

It was discovered by Elastic engineering that when elasticsearch-certutil CLI tool is used with the csr option in order to create a new Certificate Signing Requests, the associated private key that is generated is stored on disk unencrypted even if the --pass parameter is passed in the command invocation.

An issue was discovered in Kibana where a user with Viewer role could cause a Kibana instance to crash by sending a large number of maliciously crafted requests to a specific endpoint.

An issue was discovered by Elastic whereby Watcher search input logged the search query results on DEBUG log level. This could lead to raw contents of documents stored in Elasticsearch to be printed in logs. Elastic has released 8.11.2 and 7.17.16 that resolves this issue by removing this excessive logging. This issue only affects users that use Watcher and have a Watch defined that uses the search input and additionally have set the search input’s logger to DEBUG or finer, for example using: org.elasticsearch.xpack.watcher.input.search, org.elasticsearch.xpack.watcher.input, org.elasticsearch.xpack.watcher, or wider, since the loggers are hierarchical.

It was identified that under certain specific preconditions, an API key that was originally created with a specific privileges could be subsequently used to create new API keys that have elevated privileges.

A high-privileged user, allowed to create custom osquery packs 17 could affect the availability of Kibana by uploading a maliciously crafted osquery pack.