CVE Vulnerability Catalog

Memory allocation with excessive size in ES|QL query processing of Elasticsearch can lead to denial of service. An authenticated user can submit a specially crafted query whose evaluation allocates unbounded heap memory, exhausting available heap on the receiving node and causing the node to become unavailable.

Improperly controlled modification of dynamically-determined object attributes in the case management functionality of Elastic Security in Kibana can lead to unauthorized modification of case data. An authenticated user without case editing privileges can alter case records they are only entitled to view, because the case management API does not enforce the same authorization as the user interface.

Unbounded resource allocation in Kibana can lead to denial of service. An authenticated user authorized to manage maintenance windows can submit a specially crafted malformed payload that causes the Kibana process to consume excessive resources. Kibana becomes unresponsive for all users and does not recover without manual intervention.

Unbounded resource allocation in Kibana can lead to denial of service. An authenticated user with read-only privileges to the alerting feature can submit a specially crafted malformed payload that causes the Kibana process to consume excessive resources. A single request is sufficient to leave Kibana unable to serve requests for all users until the process is restarted.

Authorization bypass through user-controlled key in Kibana can lead to information disclosure. An authenticated user authorized to read alerting rules in a single Kibana space could retrieve alerting rule execution telemetry that belongs to spaces the user is not authorized to access. The disclosed telemetry includes rule identifiers, rule names, space identifiers, execution outcomes, timestamps, and execution counters.

Cleartext storage of sensitive information in an environment variable in Elastic Cloud on Kubernetes (ECK) can lead to information disclosure. When ECK reconciles a Fleet Server resource that authenticates to Elasticsearch with a service account token, the token is written into the generated workload specification in cleartext rather than being referenced from the Kubernetes Secret that ECK maintains for other credentials. Any principal able to read workload specifications in the affected namespace can read a live Elasticsearch credential, even when Kubernetes RBAC does not grant that principal access to Secrets.

Uncontrolled recursion in Elasticsearch can lead to denial of service. An authenticated user with read-only privileges on a single index can submit one specially crafted search request whose deeply nested structure is processed without a depth limit, exhausting the thread stack and terminating the affected node.

A vulnerability in Elasticsearch allows an authenticated user with read-only privileges on a single index to submit one small, specially crafted search request that causes excessive memory allocation, exhausting the JVM heap and terminating the affected node.

Kibana Agent Builder determines ownership of a private agent by comparing a stable user identifier when available, otherwise falling back to username comparison. Usernames are not unique across Elasticsearch authentication realms, so two distinct principals with the same username are treated as the same owner.

The native inference process in Elasticsearch for evaluating uploaded ML models accepts a model operation that computes a memory address from an offset without validating bounds. A user with privileges to upload and deploy models can craft a model that reads/writes memory outside the intended allocation.

The Elastic Cloud on Kubernetes (ECK) operator reads a list of secret references from an annotation on secrets it manages and accepts the namespace recorded in each reference without validating that the reference is authorized for the resource being reconciled. A user with Kubernetes permissions limited to their own namespace can write that annotation, trigger a reconcile, and cause the operator to use its cluster-wide secret permissions to copy the contents of a secret from any other namespace into a secret the user can read.

Elasticsearch does not enforce an upper bound on a user-supplied count accepted by a search highlighting option, and the allocation derived from that count is not accounted against any circuit breaker. An authenticated user with read-only privileges on a single searchable index can submit one small search request that causes the node to reserve an excessively large internal data structure. The allocation occurs before the existing highlighting safety limits are evaluated, so memory exhaustion raises a fatal error that terminates the Elasticsearch node process. This results in a denial of service for the affected node and degrades cluster routing and health. The defect is not volumetric and does not depend on the size of the indexed data, so a single request is sufficient.

Uncontrolled Recursion (CWE-674) in Elasticsearch can lead to denial of service via Input Data Manipulation (CAPEC-153). An authenticated user with low-privileged index creation permissions can submit a single request containing a specially crafted, malformed custom analysis definition that is resolved recursively without a cycle or depth check, exhausting the thread stack and terminating the affected node.

Uncontrolled Recursion (CWE-674) in the Elasticsearch wildcard matching helper can lead to a denial of service via Excessive Allocation (CAPEC-130). The matcher used to resolve wildcard patterns against names is implemented recursively and had no bound on recursion depth or on the total number of match operations performed. A search request containing a wildcard pattern with a large number of wildcard groups, evaluated against a sufficiently long name, exhausts the thread stack. Elasticsearch treats a stack overflow as an unrecoverable condition and shuts the node down, so the request terminates the affected node rather than failing gracefully.

Observable Discrepancy in Kibana Fleet leads to information disclosure. Fleet removes the Elasticsearch API key value from agent listing responses, but accepts caller-supplied filters evaluated with Kibana's internal privileges, creating a side channel to reconstruct the full API key.

Improper Privilege Management (CWE-269) in Kibana Fleet can lead to privilege escalation via Privilege Escalation (CAPEC-233). An integration policy may optionally declare extra data streams that the integration writes to, which Fleet adds to the Elasticsearch API key issued to Elastic Agents enrolled in the corresponding agent policy. The resulting key allows new documents to be inserted and index mappings to be extended for specific indices. The key does not allow reading, updating, or deleting existing documents.

Incorrect Authorization in Kibana Fleet can lead to privilege escalation. Fleet restricts some callers to managing integration policies for one specific integration, but when updating a policy, the restriction is evaluated against the stored integration rather than the replacement integration.

Authorization Bypass Through User-Controlled Key in Kibana allows unauthorized cross-space access. A user can access inference output from a trained model in another space without authorization, and can also stop or alter resources of an active model deployment.

Open WebUI from 0.9.5 before 0.10.0 allows any authenticated user to overwrite message content in a channel they do not belong to (including private and DM channels) by sending a chat completion request with a channel:-prefixed chat_id and a target message_id. Fixed in version 0.10.0.

wetty prior to version 3.0.4 decodes a base64 filename from the file-download escape sequence and interpolates it raw into a Toastify HTML string. Any output rendered by the victim containing \x1b[5i...:...\x1b[4i can run script in the wetty origin and type attacker-chosen keystrokes into the victim's SSH session.