Total
784 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2024-0241 | 1 Diaconou | 1 Encodedid\ | 2024-01-10 | N/A | 7.5 HIGH |
| encoded_id-rails versions before 1.0.0.beta2 are affected by an uncontrolled resource consumption vulnerability. A remote and unauthenticated attacker might cause a denial of service condition by sending an HTTP request with an extremely long "id" parameter. | |||||
| CVE-2023-45862 | 2 Linux, Netapp | 4 Linux Kernel, Active Iq Unified Manager, H410c and 1 more | 2024-01-08 | N/A | 5.5 MEDIUM |
| An issue was discovered in drivers/usb/storage/ene_ub6250.c for the ENE UB6250 reader driver in the Linux kernel before 6.2.5. An object could potentially extend beyond the end of an allocation. | |||||
| CVE-2023-50730 | 1 Typelevel | 1 Grackle | 2024-01-08 | N/A | 7.5 HIGH |
| Grackle is a GraphQL server written in functional Scala, built on the Typelevel stack. The GraphQL specification requires that GraphQL fragments must not form cycles, either directly or indirectly. Prior to Grackle version 0.18.0, that requirement wasn't checked, and queries with cyclic fragments would have been accepted for type checking and compilation. The attempted compilation of such fragments would result in a JVM `StackOverflowError` being thrown. Some knowledge of an applications GraphQL schema would be required to construct such a query, however no knowledge of any application-specific performance or other behavioural characteristics would be needed. Grackle uses the cats-parse library for parsing GraphQL queries. Prior to version 0.18.0, Grackle made use of the cats-parse `recursive` operator. However, `recursive` is not currently stack safe. `recursive` was used in three places in the parser: nested selection sets, nested input values (lists and objects), and nested list type declarations. Consequently, queries with deeply nested selection sets, input values or list types could be constructed which exploited this, causing a JVM `StackOverflowException` to be thrown during parsing. Because this happens very early in query processing, no specific knowledge of an applications GraphQL schema would be required to construct such a query. The possibility of small queries resulting in stack overflow is a potential denial of service vulnerability. This potentially affects all applications using Grackle which have untrusted users. Both stack overflow issues have been resolved in the v0.18.0 release of Grackle. As a workaround, users could interpose a sanitizing layer in between untrusted input and Grackle query processing. | |||||
| CVE-2023-45129 | 2 Fedoraproject, Matrix | 2 Fedora, Synapse | 2024-01-07 | N/A | 4.9 MEDIUM |
| Synapse is an open-source Matrix homeserver written and maintained by the Matrix.org Foundation. Prior to version 1.94.0, a malicious server ACL event can impact performance temporarily or permanently leading to a persistent denial of service. Homeservers running on a closed federation (which presumably do not need to use server ACLs) are not affected. Server administrators are advised to upgrade to Synapse 1.94.0 or later. As a workaround, rooms with malicious server ACL events can be purged and blocked using the admin API. | |||||
| CVE-2023-0809 | 1 Eclipse | 1 Mosquitto | 2024-01-07 | N/A | 5.3 MEDIUM |
| In Mosquitto before 2.0.16, excessive memory is allocated based on malicious initial packets that are not CONNECT packets. | |||||
| CVE-2023-3171 | 1 Redhat | 2 Enterprise Linux, Jboss Enterprise Application Platform | 2024-01-04 | N/A | 7.5 HIGH |
| A flaw was found in EAP-7 during deserialization of certain classes, which permits instantiation of HashMap and HashTable with no checks on resources consumed. This issue could allow an attacker to submit malicious requests using these classes, which could eventually exhaust the heap and result in a Denial of Service. | |||||
| CVE-2023-6563 | 1 Redhat | 6 Enterprise Linux, Keycloak, Openshift Container Platform and 3 more | 2023-12-27 | N/A | 7.7 HIGH |
| An unconstrained memory consumption vulnerability was discovered in Keycloak. It can be triggered in environments which have millions of offline tokens (> 500,000 users with each having at least 2 saved sessions). If an attacker creates two or more user sessions and then open the "consents" tab of the admin User Interface, the UI attempts to load a huge number of offline client sessions leading to excessive memory and CPU consumption which could potentially crash the entire system. | |||||
| CVE-2020-18899 | 1 Exiv2 | 1 Exiv2 | 2023-12-22 | 4.3 MEDIUM | 6.5 MEDIUM |
| An uncontrolled memory allocation in DataBufdata(subBox.length-sizeof(box)) function of Exiv2 0.27 allows attackers to cause a denial of service (DOS) via a crafted input. | |||||
| CVE-2023-5379 | 1 Redhat | 3 Jboss Enterprise Application Platform, Single Sign-on, Undertow | 2023-12-20 | N/A | 7.5 HIGH |
| A flaw was found in Undertow. When an AJP request is sent that exceeds the max-header-size attribute in ajp-listener, JBoss EAP is marked in an error state by mod_cluster in httpd, causing JBoss EAP to close the TCP connection without returning an AJP response. This happens because mod_proxy_cluster marks the JBoss EAP instance as an error worker when the TCP connection is closed from the backend after sending the AJP request without receiving an AJP response, and stops forwarding. This issue could allow a malicious user could to repeatedly send requests that exceed the max-header-size, causing a Denial of Service (DoS). | |||||
| CVE-2023-50247 | 1 Dena | 1 H2o | 2023-12-19 | N/A | 7.5 HIGH |
| h2o is an HTTP server with support for HTTP/1.x, HTTP/2 and HTTP/3. The QUIC stack (quicly), as used by H2O up to commit 43f86e5 (in version 2.3.0-beta and prior), is susceptible to a state exhaustion attack. When H2O is serving HTTP/3, a remote attacker can exploit this vulnerability to progressively increase the memory retained by the QUIC stack. This can eventually cause H2O to abort due to memory exhaustion. The vulnerability has been resolved in commit d67e81d03be12a9d53dc8271af6530f40164cd35. HTTP/1 and HTTP/2 are not affected by this vulnerability as they do not use QUIC. Administrators looking to mitigate this issue without upgrading can disable HTTP/3 support. | |||||
| CVE-2023-4486 | 1 Johnsoncontrols | 20 F4-snc, F4-snc Firmware, Nae55 and 17 more | 2023-12-19 | N/A | 7.5 HIGH |
| Under certain circumstances, invalid authentication credentials could be sent to the login endpoint of Johnson Controls Metasys NAE55, SNE, and SNC engines prior to versions 11.0.6 and 12.0.4 and Facility Explorer F4-SNC engines prior to versions 11.0.6 and 12.0.4 to cause denial-of-service. | |||||
| CVE-2023-46695 | 1 Djangoproject | 1 Django | 2023-12-14 | N/A | 7.5 HIGH |
| An issue was discovered in Django 3.2 before 3.2.23, 4.1 before 4.1.13, and 4.2 before 4.2.7. The NFKC normalization is slow on Windows. As a consequence, django.contrib.auth.forms.UsernameField is subject to a potential DoS (denial of service) attack via certain inputs with a very large number of Unicode characters. | |||||
| CVE-2023-50455 | 1 Zammad | 1 Zammad | 2023-12-13 | N/A | 7.5 HIGH |
| An issue was discovered in Zammad before 6.2.0. Due to lack of rate limiting in the "email address verification" feature, an attacker could send many requests for a known address to cause Denial Of Service (generation of many emails, which would also spam the victim). | |||||
| CVE-2023-27530 | 2 Debian, Rack Project | 2 Debian Linux, Rack | 2023-12-08 | N/A | 7.5 HIGH |
| A DoS vulnerability exists in Rack <v3.0.4.2, <v2.2.6.3, <v2.1.4.3 and <v2.0.9.3 within in the Multipart MIME parsing code in which could allow an attacker to craft requests that can be abuse to cause multipart parsing to take longer than expected. | |||||
| CVE-2023-34389 | 1 Selinc | 2 Sel-451, Sel-451 Firmware | 2023-12-06 | N/A | 6.5 MEDIUM |
| An allocation of resources without limits or throttling vulnerability in the Schweitzer Engineering Laboratories SEL-451 could allow a remote authenticated attacker to make the system unavailable for an indefinite amount of time. See product Instruction Manual Appendix A dated 20230830 for more details. | |||||
| CVE-2023-42504 | 1 Apache | 1 Superset | 2023-12-04 | N/A | 6.5 MEDIUM |
| An authenticated malicious user could initiate multiple concurrent requests, each requesting multiple dashboard exports, leading to a possible denial of service. This issue affects Apache Superset: before 3.0.0 | |||||
| CVE-2023-39322 | 1 Golang | 1 Go | 2023-11-25 | N/A | 7.5 HIGH |
| QUIC connections do not set an upper bound on the amount of data buffered when reading post-handshake messages, allowing a malicious QUIC connection to cause unbounded memory growth. With fix, connections now consistently reject messages larger than 65KiB in size. | |||||
| CVE-2023-24536 | 1 Golang | 1 Go | 2023-11-25 | N/A | 7.5 HIGH |
| Multipart form parsing can consume large amounts of CPU and memory when processing form inputs containing very large numbers of parts. This stems from several causes: 1. mime/multipart.Reader.ReadForm limits the total memory a parsed multipart form can consume. ReadForm can undercount the amount of memory consumed, leading it to accept larger inputs than intended. 2. Limiting total memory does not account for increased pressure on the garbage collector from large numbers of small allocations in forms with many parts. 3. ReadForm can allocate a large number of short-lived buffers, further increasing pressure on the garbage collector. The combination of these factors can permit an attacker to cause an program that parses multipart forms to consume large amounts of CPU and memory, potentially resulting in a denial of service. This affects programs that use mime/multipart.Reader.ReadForm, as well as form parsing in the net/http package with the Request methods FormFile, FormValue, ParseMultipartForm, and PostFormValue. With fix, ReadForm now does a better job of estimating the memory consumption of parsed forms, and performs many fewer short-lived allocations. In addition, the fixed mime/multipart.Reader imposes the following limits on the size of parsed forms: 1. Forms parsed with ReadForm may contain no more than 1000 parts. This limit may be adjusted with the environment variable GODEBUG=multipartmaxparts=. 2. Form parts parsed with NextPart and NextRawPart may contain no more than 10,000 header fields. In addition, forms parsed with ReadForm may contain no more than 10,000 header fields across all parts. This limit may be adjusted with the environment variable GODEBUG=multipartmaxheaders=. | |||||
| CVE-2022-41725 | 1 Golang | 1 Go | 2023-11-25 | N/A | 7.5 HIGH |
| A denial of service is possible from excessive resource consumption in net/http and mime/multipart. Multipart form parsing with mime/multipart.Reader.ReadForm can consume largely unlimited amounts of memory and disk files. This also affects form parsing in the net/http package with the Request methods FormFile, FormValue, ParseMultipartForm, and PostFormValue. ReadForm takes a maxMemory parameter, and is documented as storing "up to maxMemory bytes +10MB (reserved for non-file parts) in memory". File parts which cannot be stored in memory are stored on disk in temporary files. The unconfigurable 10MB reserved for non-file parts is excessively large and can potentially open a denial of service vector on its own. However, ReadForm did not properly account for all memory consumed by a parsed form, such as map entry overhead, part names, and MIME headers, permitting a maliciously crafted form to consume well over 10MB. In addition, ReadForm contained no limit on the number of disk files created, permitting a relatively small request body to create a large number of disk temporary files. With fix, ReadForm now properly accounts for various forms of memory overhead, and should now stay within its documented limit of 10MB + maxMemory bytes of memory consumption. Users should still be aware that this limit is high and may still be hazardous. In addition, ReadForm now creates at most one on-disk temporary file, combining multiple form parts into a single temporary file. The mime/multipart.File interface type's documentation states, "If stored on disk, the File's underlying concrete type will be an *os.File.". This is no longer the case when a form contains more than one file part, due to this coalescing of parts into a single file. The previous behavior of using distinct files for each form part may be reenabled with the environment variable GODEBUG=multipartfiles=distinct. Users should be aware that multipart.ReadForm and the http.Request methods that call it do not limit the amount of disk consumed by temporary files. Callers can limit the size of form data with http.MaxBytesReader. | |||||
| CVE-2022-2879 | 1 Golang | 1 Go | 2023-11-25 | N/A | 7.5 HIGH |
| Reader.Read does not set a limit on the maximum size of file headers. A maliciously crafted archive could cause Read to allocate unbounded amounts of memory, potentially causing resource exhaustion or panics. After fix, Reader.Read limits the maximum size of header blocks to 1 MiB. | |||||