| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| 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. |
| 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. |
| 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. |
| 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. |
| 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. |
| 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. |
| 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. |
| Unauthenticated Denial of Service Attack in Really Simple SSL <= 9.8.0 versions. |
| Netty is a network application framework for development of protocol servers and clients. Prior to versions 4.1.135.Final and 4.2.15.Final, SslClientHelloHandler.decode() reads the 24-bit TLS handshake length and, when the ClientHello does not fit in the first record, eagerly allocates `ctx.alloc().buffer(handshakeLength)` (line 161). The guard at line 140 is `handshakeLength > maxClientHelloLength && maxClientHelloLength != 0`, and the commonly-used SniHandler/AbstractSniHandler constructors (SniHandler(Mapping), SniHandler(AsyncMapping), AbstractSniHandler()) pass maxClientHelloLength=0 and handshakeTimeoutMillis=0, so the length guard is disabled and no timeout is scheduled. A 16 MiB request exceeds the default pooled chunk size and becomes a huge/unpooled allocation performed immediately. The buffer is retained in the handler until the channel closes. Versions 4.1.135.Final and 4.2.15.Final patch the issue. |
| 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. |
| 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. |
| 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. |
| Impact:
The undici WebSocket client enforces maxPayloadSize on the cumulative byte count of fragments in a message but does not enforce a limit on the number of fragments. A malicious WebSocket server can stream many small or empty continuation frames that each pass per-frame and cumulative-size validation, collectively causing unbounded memory growth in the client process. The result is memory exhaustion and a denial of service.
Affected applications are those using the undici WebSocket client (new WebSocket(...)) or the WebSocketStream API that can be induced to connect to an attacker-controlled or compromised WebSocket endpoint.
All releases starting at undici 6.17.0 are affected.
Patches: Upgrade to undici >= 6.26.0, >= 7.28.0, or >= 8.5.0. Workarounds:
No workaround is available. The fix must be applied through an upgrade. |
| 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. |
| 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. |
| 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. |
| 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. |
| In Reactor Core, applications that use the Flux.bufferTimeout operator with fairBackpressure enabled are vulnerable to a Denial of Service (DoS) condition.
Reactor Core 3.8.0 - 3.8.6
Reactor Core 3.7.19 and earlier |
| go-libp2p is the Go implementation of the libp2p Networking Stack. Prior to versions 0.27.8, 0.28.2, and 0.29.1 malicious peer can use large RSA keys to run a resource exhaustion attack & force a node to spend time doing signature verification of the large key. This vulnerability is present in the core/crypto module of go-libp2p and can occur during the Noise handshake and the libp2p x509 extension verification step. To prevent this attack, go-libp2p versions 0.27.8, 0.28.2, and 0.29.1 restrict RSA keys to <= 8192 bits. To protect one's application, it is necessary to update to these patch releases and to use the updated Go compiler in 1.20.7 or 1.19.12. There are no known workarounds for this issue. |
| A flaw was found in libssh. A malicious SFTP server can send responses for unknown request IDs that libssh clients keep queued indefinitely, causing unbounded memory growth and client-side denial of service. |
