Vulnerabilities
All
My stack
Known exploited
Public exploit
Critical (9+)
Likely exploited (EPSS ≥ 50%)
Changed, 24 h
New, 24 h
Sort:
risk
modified
published
CVSS
EPSS
| CVE | CVSS | EPSS | Vendor, product | Description | Modified |
|---|---|---|---|---|---|
| CVE-2026-46453exploit | 5.3 medium | 1.0% | apache, camel | Improper Input Validation, Authorization Bypass Through User-Controlled Key vulnerability in Apache Camel ElasticSearch Rest Client. The camel-elasticsearch-rest-client component reads several Exchange headers to control its behaviour - SEARCH_QUERY (an advanced query body), OPERATION (which Elasticsearch operation to run), INDEX_NAME, INDEX_SETTINGS and ID. The string values of these header constants, defined in ElasticSearchRestClientConstant, are plain unprefixed names ('SEARCH_QUERY', 'OPERATION', 'INDEX_NAME', 'INDEX_SETTINGS', 'ID') rather than the 'Camel'-prefixed names used by every other Camel component (for example CamelSqlQuery, CamelMongoDbCriteria, CamelCqlQuery). Camel's inbound HTTP header filter, HttpHeaderFilterStrategy, blocks only header names that begin with 'Camel' or 'camel'. Because the Elasticsearch header names do not carry that prefix, they pass through the inbound filter unchanged. When a Camel route exposes an HTTP entry point (for example platform-http) in front of an elasticsearch-rest-client producer, an untrusted HTTP client can set these headers directly on its request and override the query and operation that the route author configured: reading every document in the index (SEARCH_QUERY with a match_all query), deleting documents (OPERATION set to Delete together with ID), or exfiltrating selected fields. No credentials are required and the producer reads the headers unconditionally. This issue affects Apache Camel: from 4.3.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0. Users are recommended to upgrade to version 4.21.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.8. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.3. The fix renames the camel-elasticsearch-rest-client Exchange header constant string values (ID, SEARCH_QUERY, INDEX_SETTINGS, INDEX_NAME, OPERATION) to carry the Camel prefix (CamelElasticsearchId, CamelElasticsearchSearchQuery, CamelElasticsearchIndexSettings, CamelElasticsearchIndexName, CamelElasticsearchOperation) so that they are blocked by the inbound HttpHeaderFilterStrategy; the Java field names are unchanged. For deployments that cannot upgrade immediately, strip the affected headers from untrusted inbound messages before they reach the producer (for example removeHeader('SEARCH_QUERY'), removeHeader('OPERATION'), removeHeader('INDEX_NAME'), removeHeader('INDEX_SETTINGS') and removeHeader('ID') in front of the elasticsearch-rest-client endpoint), or apply a custom HeaderFilterStrategy that blocks these names. | Sun 25 Oct |
| CVE-2025-44824 | 6.5 medium | 3.0% | nagios, log_server | Nagios Log Server before 2024R1.3.2 allows authenticated users (with read-only API access) to stop the Elasticsearch service via a /nagioslogserver/index.php/api/system/stop?subsystem=elasticsearch call. The service stops even though "message": "Could not stop elasticsearch" is in the API response. This is GL:NLS#474. | 8 Oct |
| CVE-2025-12977 | 9.1 critical | 1.0% | treasuredata, fluent_bit | Fluent Bit in_http, in_splunk, and in_elasticsearch input plugins fail to sanitize tag_key inputs. An attacker with network access or the ability to write records into Splunk or Elasticsearch can supply tag_key values containing special characters such as newlines or ../ that are treated as valid tags. Because tags influence routing and some outputs derive filenames or contents from tags, this can allow newline injection, path traversal, forged record injection, or log misrouting, impacting data integrity and log routing. | 18 Oct |
| CVE-2026-19111 | 8.6 high | 1.0% | no CPE yet | Insecure direct object reference in the mongodb_memory, elasticsearch_memory, and mem0_memory tools in Amazon Strands Agents Tools before 0.8.3 might allow remote authenticated users to access, modify, or delete memories belonging to other tenants by influencing the LLM to emit tool calls with a forged namespace parameter. To remediate this issue, users should upgrade to version 0.8.3. | Fri 23 Oct |
| CVE-2026-35211 | 6.5 medium | 1.0% | citeum, opencti | OpenCTI is an open source platform for managing cyber threat intelligence knowledge and observables. Prior to 7.260401.0, the OpenCTI GraphQL API exposes a script filter operator in its FilterOperator enum that allows any authenticated user with the KNOWLEDGE capability to pass user-supplied Elasticsearch Painless script values directly into search queries without validation or sanitization, allowing computationally expensive scripts to consume cluster CPU resources and degrade or deny service for all users. This issue is fixed in version 7.260401.0. | Sun 25 Oct |
| CVE-2026-56149 | 4.9 medium | 1.0% | elastic, elasticsearch | Allocation of Resources Without Limits or Throttling (CWE-770) in Elasticsearch can lead to a denial of service via Excessive Allocation (CAPEC-130). A user with elevated privileges can submit a specially crafted machine learning request that causes excessive memory consumption, which may render the affected node unavailable. | Sun 25 Oct |
| CVE-2026-31215 | 9.1 critical | 0.00% | nexent | The nexent v1.7.5.2 backend service contains an unauthorized arbitrary file deletion vulnerability in its ElasticSearch service interface. The DELETE /{index_name}/documents endpoint lacks proper authentication and authorization controls and does not validate the user-supplied path_or_url parameter. This allows unauthenticated remote attackers to send crafted requests that trigger the deletion of arbitrary documents from ElasticSearch indices and corresponding files from the MinIO storage system. Successful exploitation leads to data destruction and denial of service. | 19 Oct |
| CVE-2026-102406 | 8.8 high | 0.00% | elastic, kibana | Authorization Bypass Through User-Controlled Key (CWE-639) in Kibana could lead to cross-tenant data interception. In this context, "tenant" refers to a user or team sharing the same Kibana deployment, not a separate Elastic Cloud organization or customer. Kibana's Fleet package installation process allowed a user holding delegated Fleet package-management privileges, without direct Elasticsearch administrative privileges, to claim a data stream identifier already in use by another tenant. Because ownership of that identifier was not verified before Fleet applied the uploaded package's generated index and ingest-pipeline settings to already-existing infrastructure, an attacker could redirect an existing tenant's data stream through infrastructure under their control. This exposed the affected tenant's subsequently ingested data to unauthorized disclosure and modification, and prevented that data from reaching its intended destination. Interception could continue even after the malicious package was removed, requiring separate remediation of the affected infrastructure. | 13 Oct |
| CVE-2026-47835 | 7.5 high | 0.00% | vmware, spring_ai | In Spring AI Vector Stores, special characters could be used to force the execution of arbitrary queries in Elasticsearch, OpenSearch, and GemFire VectorDB. Affected components: spring-ai-elasticsearch-store, spring-ai-opensearch-store, spring-ai-gemfire-store. Affected versions: Spring AI 1.0.0 through 1.0.x (fix 1.0.9). Spring AI 1.1.0 through 1.1.x (fix 1.1.8). | Sun 25 Oct |
| CVE-2026-103007 | 7.2 high | 0.00% | elastic, elasticsearch | Incorrect Authorization (CWE-863) in Elasticsearch can lead to Privilege Escalation via a delegated administrative privilege whose scope is not fully enforced during authorization checks. Elasticsearch contains an incorrect authorization weakness in a configurable, non-default privilege that lets an administrator delegate limited role-management capability to another user, scoped to specific indices. The authorization check that enforces this scoping does not correctly account for a role-definition setting that can expand the matched index set. A user holding this delegated privilege with a broadly-scoped index pattern can exploit this inconsistency by updating their own assigned role to gain access to indices that should remain restricted, including internal security data. This can enable further escalation up to full administrative control of the cluster. | 9 Oct |
| CVE-2026-111906 | 7.1 high | 0.00% | no CPE yet | phpMyFAQ before 4.1.9 and 4.2.0-alpha before 4.2.0-beta contains a cross-site request forgery vulnerability in the Elasticsearch and OpenSearch administration API endpoints, which do not validate a CSRF token for the create, drop, and import actions. Attackers can lure a user with CONFIGURATION_EDIT permission to a malicious page that triggers these actions, deleting search indexes, forcing re-indexing, or exhausting resources. | 19 Oct |
| CVE-2026-103009 | 7.1 high | 0.00% | elastic, elasticsearch | Authorization Bypass Through User-Controlled Key (CWE-639) in Elasticsearch can lead to Information Disclosure via a specially crafted cross-cluster search request that references an unauthorized shard identifier. Elasticsearch contains an authorization bypass weakness in its handling of cross-cluster search requests made through the Remote Cluster Security (RCS) 2.0 model. An authorization check validates a request against one identifying attribute of the target shard, while a separate, independently-supplied identifying attribute in the same request determines which shard is actually accessed. A holder of a cross-cluster API key authorized for one index can craft a request whose two identifying attributes refer to different indices, causing the request to be authorized against an index they can access while actually operating against a different, unauthorized index. This can expose that index's document contents, field mappings, and other metadata, and in limited cases allows modification of retention-lease state on the unauthorized index. | 9 Oct |
| CVE-2026-15746 | 6.9 medium | 0.00% | no CPE yet | Strands Agents is an open-source Python SDK for building and running AI agents. The strands-agents-tools package provides pre-built tools for use with the SDK, including the elasticsearch_memory tool for agent memory storage. We identified CVE-2026-15746, a server-side request forgery (SSRF) issue in the elasticsearch_memory tool. The tool exposed its connection parameters (es_url, cloud_id, api_key) as fields the large language model (LLM) could control through the tool schema. When a caller omitted the api_key parameter, the tool fell back to the operator's ELASTICSEARCH_API_KEY environment variable and sent it to whichever host the LLM specified. A crafted prompt could cause the tool to connect to a threat-actor-controlled server and disclose the operator's Elasticsearch API key in the Authorization header. We recommend you upgrade to strands-agents-tools version 0.7.0 or later. As a precautionary measure, we recommend all operators rotate their ELASTICSEARCH_API_KEY, even if there is no indication the credential was exposed. | Sat 24 Oct |
| CVE-2026-40970 | 6.8 medium | 0.00% | vmware, spring_boot | When configured to use an SSL bundle, Spring Boot's Elasticsearch auto-configuration does not perform hostname verification when connecting to the Elasticsearch server. Affected: Spring Boot 4.0.0–4.0.5; upgrade to 4.0.6 or later per vendor advisory. | Mon 26 Oct |
| CVE-2026-41018 | 6.5 medium | 0.00% | apache, apache-airflow-providers-elasticsearch | The Elasticsearch logging provider, when configured with a `host` URL that embeds credentials (for example `https://user:[email protected]:9200`), wrote the full host URL — including the embedded credentials — into task logs. Any user with task-log read permission could harvest the backend credentials. Users are advised to upgrade to `apache-airflow-providers-elasticsearch` 6.5.3 or later and, as a defense-in-depth measure, configure the backend credentials via a secret backend rather than embedding them in the `[elasticsearch] host` URL. | Mon 26 Oct |
| CVE-2026-56148 | 6.5 medium | 0.00% | elastic, elasticsearch | Uncontrolled Recursion (CWE-674) in Elasticsearch can lead to a denial of service via Excessive Allocation (CAPEC-130). An authenticated user can submit a specially crafted query that causes excessive resource consumption while the request is processed, which may render the affected node unavailable. | Sun 25 Oct |
| CVE-2026-49090 | 6.5 medium | 0.00% | elastic, elasticsearch | Uncontrolled Resource Consumption (CWE-400) in Elasticsearch can lead to a denial of service via Excessive Allocation (CAPEC-130). An authenticated user can submit a specially crafted bulk request that causes sustained high CPU consumption, which can render the affected node unable to process requests. | Sun 25 Oct |
| CVE-2026-56144 | 6.5 medium | 0.00% | elastic, elasticsearch | Incorrect Authorization (CWE-863) in Elasticsearch can allow an authenticated user with limited index privileges to exploit insufficient authorization controls in the ingest simulation feature. By targeting indices they are not authorized to access directly, the user can cause those indices' configured ingest pipelines to execute and return their output, potentially disclosing data processed or enriched by those pipelines. Additionally, the same feature can be used to retrieve index mapping metadata for indices the user are not authorized to access directly. | Sat 24 Oct |
| CVE-2026-56145 | 6.5 medium | 0.00% | elastic, elasticsearch | Uncontrolled Resource Consumption (CWE-400) in Elasticsearch can lead to denial of service via Excessive Allocation (CAPEC-130). A low-privileged authenticated user with permission to execute EQL sequence queries against an index they control can send a specially crafted query that triggers excessive memory consumption, causing the Elasticsearch node to crash. | Sat 24 Oct |
| CVE-2026-63136 | 6.5 medium | 0.00% | elastic, elasticsearch | Uncontrolled Resource Consumption (CWE-400) in Elasticsearch can lead to denial of service via Excessive Allocation (CAPEC-130). A user with search privileges can submit a specially crafted search request that causes a data node to exhaust available heap memory, resulting in node unavailability and cluster degradation. An attacker could leverage this vulnerability to cause cluster downtime requiring manual intervention to restore service. | Sat 24 Oct |
| CVE-2026-63140 | 6.5 medium | 0.00% | elastic, elasticsearch | Reachable Assertion (CWE-617) in Elasticsearch can lead to denial of service via Input Data Manipulation (CAPEC-153). A specially crafted search request containing a null value in a specific query clause causes an internal assertion to be raised during query parsing. Because Elasticsearch treats assertion failures as fatal errors, this terminates the affected node process. A low-privileged authenticated user with read access to at least one index can exploit this condition with a single request to cause a node to terminate, disrupting search availability. In a single-node deployment this fully stops Elasticsearch; in a multi-node cluster it reduces cluster capacity for each affected node. | Sat 24 Oct |
| CVE-2026-63144 | 6.5 medium | 0.00% | elastic, elasticsearch | Uncontrolled Recursion (CWE-674) in Elasticsearch can lead to denial of service via a specially crafted search request submitted by a low-privileged authenticated user. A user with read-level index access can submit a request that triggers unbounded recursive processing within the Elasticsearch query evaluation component, causing a fatal error that terminates the affected node. In single-node deployments, this results in complete service outage; in multi-node clusters, it causes repeated node restarts and sustained availability degradation. | Sat 24 Oct |
| CVE-2026-63263 | 6.5 medium | 0.00% | elastic, elasticsearch | Uncontrolled Resource Consumption (CWE-400) in Elasticsearch can lead to denial of service via Exponential Data Expansion (CAPEC-197). An authenticated user may submit a specially crafted query to the ES|QL engine that causes exponential CPU consumption during query evaluation. Because the resource exhaustion persists beyond query completion, repeated requests can fully exhaust the available query worker resources, rendering ES|QL queries unavailable until the node is restarted. | Sat 24 Oct |
| CVE-2026-102404 | 6.5 medium | 0.00% | elastic, elasticsearch | Uncontrolled Resource Consumption (CWE-400) in Elasticsearch can lead to denial of service via Excessive Allocation (CAPEC-130). A low-privileged authenticated user can submit a specially crafted query that causes uncontrolled memory growth in the query processing engine, resulting in an out-of-memory condition that terminates the Elasticsearch node. The condition can be triggered repeatedly, including by queries embedded in shared resources, causing persistent cluster unavailability. | 13 Oct |
| CVE-2026-102409 | 6.5 medium | 0.00% | elastic, elasticsearch | Uncontrolled Recursion (CWE-674) in Elasticsearch can allow an authenticated user with low privileges to terminate an Elasticsearch node, resulting in denial of service, via Excessive Allocation (CAPEC-130). | 13 Oct |
| CVE-2026-102411 | 6.5 medium | 0.00% | elastic, elasticsearch | Allocation of Resources Without Limits or Throttling (CWE-770) in Elasticsearch can lead to Denial of Service via Excessive Allocation (CAPEC-130). Elasticsearch enforces a size limit on the user-supplied metadata field for each individual template resource, but does not limit the total memory used when multiple such resources are retrieved together. A user holding the *manage_index_templates* cluster privilege can register multiple resources each within the individual limit. Retrieving them together materializes all of their metadata values in memory at once, exhausting available heap and causing the affected node to fail with an out-of-memory error, resulting in a denial of service. | 9 Oct |
| CVE-2026-103005 | 6.5 medium | 0.00% | elastic, elasticsearch | Memory Allocation with Excessive Size Value (CWE-789) in Elasticsearch can lead to denial of service via Excessive Allocation (CAPEC-130). An authenticated user with connector management privileges could cause the cluster to allocate an uncontrolled amount of memory when connector resources with an excessively large `description` field are created and subsequently accessed, exhausting available heap memory and crashing the affected node. | 9 Oct |
| CVE-2026-103006 | 6.5 medium | 0.00% | elastic, elasticsearch | Uncontrolled Recursion (CWE-674) in Elasticsearch can lead to Denial of Service via a specially crafted, deeply nested request submitted to the aggregation feature of the search API. Elasticsearch contains an uncontrolled recursion weakness in its search aggregation processing. An authenticated user with read access to a single index can submit a specially crafted request containing deeply nested aggregation definitions. Processing this request triggers unbounded recursive execution that exhausts the server process's available resources, causing the affected node to terminate. The node does not recover automatically and requires manual intervention to restore service. | 9 Oct |
| CVE-2026-103008 | 6.5 medium | 0.00% | elastic, elasticsearch | Uncontrolled Recursion (CWE-674) in Elasticsearch can lead to Denial of Service via a specially crafted request that causes the server to construct and process a deeply nested data structure with no bound on recursion depth. Elasticsearch contains an uncontrolled recursion weakness in how it builds and serializes geometry values produced by scripted runtime fields. Unlike geometry supplied as text, which is subject to a nesting-depth limit, geometry constructed from a script's output is not bounded. An authenticated user with read access to a single index can submit a request defining such a field with a script that produces a deeply nested structure. Processing this request recurses past the available stack space, causing the affected node to terminate. The node does not recover automatically on all deployments and may require manual intervention to restore service. | 9 Oct |
| CVE-2025-37727 | 5.7 medium | 0.00% | elastic, elasticsearch | Insertion of sensitive information in log file in Elasticsearch can lead to loss of confidentiality under specific preconditions when auditing requests to the reindex API https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-reindex | 8 Oct |
| CVE-2026-42401 | 5.4 medium | 0.00% | elastic, kibana | Improper Neutralization of Input During Web Page Generation (CWE-79) in Kibana can lead to stored HTML injection. A user with write access to an Elasticsearch index could persist crafted markup which, when subsequently rendered through an affected Kibana view by another user, was not sufficiently sanitized. Successful exploitation could result in unauthorized UI manipulation and outbound network requests issued from the viewing user's browser session. | 14 Oct |
| CVE-2026-102407 | 5.4 medium | 0.00% | elastic, elasticsearch | Incorrect Authorization (CWE-863) in Elasticsearch can lead to unauthorized data stream modification via Accessing Functionality Not Properly Constrained by ACLs (CAPEC-1). An authenticated user with sufficient privileges over a single resource could use the Modify Data Streams API to modify a data stream to which they were not otherwise authorized, potentially injecting data into it or affecting its ability to be searched normally. This issue does not allow an attacker to read the contents of a data stream they do not otherwise have access to. | 13 Oct |
| CVE-2025-12978 | 5.4 medium | 0.00% | treasuredata, fluent_bit | Fluent Bit in_http, in_splunk, and in_elasticsearch input plugins contain a flaw in the tag_key validation logic that fails to enforce exact key-length matching. This allows crafted inputs where a tag prefix is incorrectly treated as a full match. A remote attacker with authenticated or exposed access to these input endpoints can exploit this behavior to manipulate tags and redirect records to unintended destinations. This compromises the authenticity of ingested logs and can allow injection of forged data, alert flooding and routing manipulation. | 8 Oct |
| CVE-2026-45009 | 5.3 medium | 0.00% | no CPE yet | phpMyFAQ before 4.1.2 contains an insufficient authorization vulnerability in admin-api routes that allows authenticated ordinary users to access administrative endpoints by only checking login status instead of verifying backend privileges. Attackers with valid frontend user accounts can access sensitive backend operational information including dashboard versions, LDAP configuration, Elasticsearch statistics, and health-check data. | Mon 26 Oct |
| CVE-2026-106562 | 4.3 medium | 0.00% | linuxfoundation, backstage\/plugin-search-backend, backstage\/plugin-search-backend-module-elasticsearch, backstage | Backstage is an open framework for building developer portals. Prior to 2.1.6 in @backstage/plugin-search-backend and 1.8.7 in @backstage/plugin-search-backend-module-elasticsearch, search engine permission filtering could return documents denied by policy. An authenticated Backstage user subject to a DENY policy for search document types could receive unauthorized results in deployments with permission.enabled set to true and an Elasticsearch or OpenSearch backend. This issue is fixed in @backstage/plugin-search-backend 2.1.6 and @backstage/plugin-search-backend-module-elasticsearch 1.8.7. | 16 Oct |
| CVE-2026-102408 | 4.3 medium | 0.00% | elastic, elasticsearch | Inefficient Regular Expression Complexity (CWE-1333) in Elasticsearch can lead to denial of service via Regular Expression Exponential Blowup (CAPEC-492). The ES|QL CHUNK function's recursive chunking strategy accepts a list of user-supplied regular expressions used as text-splitting separators, without validating their computational complexity or bounding their execution time. An authenticated user with read access to any text-based index can submit a specially crafted regular expression that triggers catastrophic backtracking, consuming excessive CPU on Elasticsearch worker threads and degrading query throughput for other tenants on the affected node. The cluster does not crash as a result of this issue. | 13 Oct |
36 of 36
Download these 36 as CSV · subscribe to this list.
EPSS scores: 2026-10-28. NVD cursor: 2026-10-29 00:22. The News page shows only notable CVEs (KEV, your stack, new criticals, EPSS over 50%, or active exploitation per SSVC); this table has all of them.