Total
2669 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-59289 | 2 Spring, Vmware | 2 Spring For Graphql, Spring For Graphql | 2026-09-02 | 7.5 High |
| Spring for GraphQL's Spring Data pagination support resolves arguments of a scrollable query and forwards the client-supplied values to the underlying repository. An attacker can forge a malicious query for a Connection field that can exhaust application memory or place significant, prolonged load on the underlying datastore, resulting in a Denial of Service. Spring for GraphQL 2.0.0 - 2.0.4 Spring for GraphQL 1.4.0 - 1.4.6 Spring for GraphQL 1.2.0 - 1.3.9 | ||||
| CVE-2026-59287 | 2 Spring, Vmware | 2 Spring For Graphql, Spring For Graphql | 2026-09-02 | 5.9 Medium |
| Spring for GraphQL is vulnerable to Denial of Service attacks when using the WebSocket client with keepAlive enabled. Spring for GraphQL 2.0.0 - 2.0.4 Spring for GraphQL 1.4.0 - 1.4.6 Spring for GraphQL 1.3.0 - 1.3.9 | ||||
| CVE-2026-84311 | 1 Py-pdf | 1 Pypdf | 2026-09-02 | 5.5 Medium |
| pypdf is a free and open-source pure-python PDF library. Prior to 6.16.1, an attacker can craft a PDF that causes pypdf/_page.py PageObject._extract_text and PageObject.extract_xform_text to traverse a directed acyclic graph of reused form XObjects in which each form invokes a child multiple times, creating exponentially many traversal paths and causing long runtimes and large memory consumption. This issue is fixed in version 6.16.1. | ||||
| CVE-2026-58063 | 2 Bouncycastle, Legion Of The Bouncy Castle Inc. | 6 Bc-java, Bouncy Castle For Java Lts, Fips Java Api and 3 more | 2026-09-02 | 5.3 Medium |
| In Bouncy Castle for Java before 1.85, BCFKS keystore load honours unbounded KDF cost from untrusted file. This issue also affects Bouncy Castle for Java LTS before 2.73.12, and Bouncy Castle for Java FIPS (BC-FJA) before bc-fips 1.0.2.7 (1.0.X series), 2.0.2 (2.0.X series) and 2.1.3 (2.1.X series). | ||||
| CVE-2026-72682 | 1 Elastic | 1 Kibana | 2026-09-02 | 6.5 Medium |
| Allocation of Resources Without Limits or Throttling (CWE-770) in Kibana can lead to a denial of service via Excessive Allocation (CAPEC-130). An authenticated user holding only low, read-level Agent Builder privileges could submit a specially crafted request that causes Kibana to consume an unbounded amount of memory, terminating the process and denying service to all users of the instance. | ||||
| CVE-2026-72652 | 1 Elastic | 1 Kibana | 2026-09-02 | 6.5 Medium |
| Allocation of Resources Without Limits or Throttling (CWE-770) in Kibana can lead to a denial of service via Excessive Allocation (CAPEC-130). An authenticated user can submit a specially crafted request that causes excessive resource consumption, which may render Kibana unavailable. | ||||
| CVE-2026-72659 | 1 Elastic | 1 Kibana | 2026-09-02 | 6.5 Medium |
| Allocation of Resources Without Limits or Throttling (CWE-770) in Kibana can lead to denial of service via Excessive Allocation (CAPEC-130). A specially crafted, malformed payload submitted to a Kibana visualization feature by an authenticated user holding only low-privileged access is not correctly validated before use. Processing the request causes unbounded memory growth in the Kibana process, which is terminated by the host once available memory is exhausted. Kibana then becomes unavailable to all users until the service is restarted. | ||||
| CVE-2026-72653 | 1 Elastic | 1 Kibana | 2026-09-02 | 6.5 Medium |
| Allocation of Resources Without Limits or Throttling (CWE-770) in Kibana can lead to denial of service via Excessive Allocation (CAPEC-130). An authenticated user who is authorized to manage maintenance windows could 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. | ||||
| CVE-2026-72651 | 1 Elastic | 1 Kibana | 2026-09-02 | 6.5 Medium |
| Allocation of Resources Without Limits or Throttling (CWE-770) in Kibana can lead to denial of service via Excessive Allocation (CAPEC-130). An authenticated user with read-only privileges to the alerting feature could 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. | ||||
| CVE-2026-49089 | 1 Elastic | 1 Kibana | 2026-09-02 | 6.5 Medium |
| Allocation of Resources Without Limits or Throttling (CWE-770) in Kibana can lead to denial of service via Excessive Allocation (CAPEC-130). A query expression accepted by a connector reporting operation was processed without any limit on its size, and an oversized expression caused the Kibana process to spend an unbounded amount of time evaluating it. An authenticated user with read-only privileges was able to send a single request that left Kibana unable to serve any user until the process was restarted. | ||||
| CVE-2026-72667 | 1 Elastic | 1 Kibana | 2026-09-02 | 6.5 Medium |
| Allocation of Resources Without Limits or Throttling (CWE-770) in Kibana can lead to a denial of service via Excessive Allocation (CAPEC-130). A specially crafted request submitted by an authenticated user with minimal privileges to a validation capability of the Observability log analysis feature causes Kibana to perform an unbounded amount of concurrent work. This can exhaust the memory available to the Kibana process and make Kibana unavailable to all users until it is restarted. The severity of the outcome depends on the resources allocated to the deployment; on well-provisioned deployments a single request may cause degraded performance and elevated memory pressure rather than a full outage, but the request is inexpensive to repeat. | ||||
| CVE-2026-33465 | 1 Elastic | 1 Kibana | 2026-09-02 | 6.5 Medium |
| Allocation of Resources Without Limits or Throttling (CWE-770) in Kibana can lead to a denial of service via Excessive Allocation (CAPEC-130). An authenticated user with low-level permissions could submit a specially crafted request that causes excessive resource consumption, which may render Kibana unavailable. | ||||
| CVE-2026-72674 | 1 Elastic | 1 Kibana | 2026-09-02 | 6.5 Medium |
| Allocation of Resources Without Limits or Throttling (CWE-770) in Kibana can lead to a denial of service via Excessive Allocation (CAPEC-130). A user-supplied list of document fields accepted by the Kibana Playground for RAG feature was neither bounded in length nor de-duplicated before it was used to assemble the response for each matching document. A single crafted request could therefore make Kibana build a response far larger than the data it was derived from, and the resulting processing and memory pressure exhausts the resources of the Kibana instance. | ||||
| CVE-2026-84775 | 2 Really-simple-plugins, Wordpress | 2 Really Simple Ssl, Wordpress | 2026-09-02 | 5.3 Medium |
| Unauthenticated Denial of Service Attack in Really Simple SSL <= 9.8.0 versions. | ||||
| CVE-2026-40984 | 1 Spring | 1 Micrometer | 2026-09-02 | 7.5 High |
| In Micrometer, it is possible for a user to provide specially crafted HTTP requests that may cause a denial-of-service (DoS) condition. Affected versions: micrometer-core 1.16.0 through 1.16.5; 1.15.0 through 1.15.11; 1.14.0 through 1.14.15; 1.13.0 through 1.13.18; 1.9.0 through 1.9.17. micrometer-jetty11 1.16.0 through 1.16.5; 1.15.0 through 1.15.11; 1.14.0 through 1.14.15; 1.13.0 through 1.13.18. micrometer-jetty12 1.16.0 through 1.16.5; 1.15.0 through 1.15.11; 1.14.0 through 1.14.15; 1.13.0 through 1.13.18. | ||||
| CVE-2026-40983 | 1 Spring | 1 Micrometer | 2026-09-02 | 7.5 High |
| In Micrometer, it is possible for a user to provide specially crafted gRPC requests that may cause a denial-of-service (DoS) condition. Affected versions: Micrometer 1.16.0 through 1.16.5; 1.15.0 through 1.15.11. | ||||
| CVE-2026-26445 | 2026-09-02 | 7.5 High | ||
| stomper 5e2741e is vulnerable to Denial of Service. A malicious client can send partial STOMP frames and keep the TCP connections open, which, combined with the broker s use of edge-triggered epoll (EPOLLET) and MSG_PEEK in recv(), causes sockets to enter a permanent half-read state. When enough such connections accumulate, the broker stops receiving any further epoll events for those sockets and eventually hangs in epoll_wait, effectively refusing to process new messages. | ||||
| CVE-2024-39478 | 1 Linux | 1 Linux Kernel | 2026-09-02 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: crypto: starfive - Do not free stack buffer RSA text data uses variable length buffer allocated in software stack. Calling kfree on it causes undefined behaviour in subsequent operations. | ||||
| CVE-2026-30073 | 1 Free5gc | 1 Free5gc | 2026-09-02 | 7.5 High |
| An issue in the NssaiAvailabilitySubscriptionCreate component of free5gc v4.0.1 allows attackers to cause a Denial of Service (DoS) via a crafted POST request. | ||||
| CVE-2026-71257 | 1 Apache | 1 Wicket | 2026-09-02 | 7.5 High |
| Apache Wicket enforces the upload limits configured on a form or upload field while parsing a multipart request with Apache Commons FileUpload. If the request body has already been consumed by another component, Commons FileUpload returns no items and Wicket falls back to reading the upload through HttpServletRequest#getParts(). The per-file size limit (for example Form#setFileMaxSize) and the file count limit (Form#setFileCountMax) are not applied to the parts obtained that way, and no exception is raised, so the upload is processed as though those limits had been satisfied. A remote uploader can therefore submit files that are larger, or more numerous, than the application permits, up to whatever the component that parsed the request allows. A part carrying no Content-Type header is additionally read into memory in full during parsing, so the size of that allocation is determined by the request and bounded only by those same external limits. The total upload size limit (Form#setMaxSize) is not affected. Commons FileUpload compares the declared Content-Length against it before reading the body, so a request declaring an oversized length is rejected before the fallback is reached. The fallback is reached in deployments where a servlet or filter has already parsed the request body — for example a servlet annotated with @MultipartConfig, Spring Boot's multipart resolver, or any filter that calls HttpServletRequest#getParameter() on a multipart request. It applies to the Wicket components that accept uploads on that path, including Form with FileUploadField, FileUploadToResourceField and AjaxFileDropBehavior. Applications that configure neither a per-file nor a file-count limit are not affected, as Wicket applies neither by default. This issue affects Apache Wicket: from 8.0.0 through 8.18.0, from 9.0.0 through 9.23.0, from 10.0.0 through 10.10.0. Users are recommended to upgrade to version 8.19.0, 9.24.0 or 10.11.0, which fix the issue. Users of Apache Wicket 7.x or older, which are no longer supported, should upgrade to a supported version. As a workaround, configure equivalent limits in the component that parses the request — for example spring.servlet.multipart.max-file-size and max-request-size, or maxFileSize and maxRequestSize in @MultipartConfig or in the web.xml <multipart-config> element. | ||||