Total
2358 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2022-41921 | 1 Discourse | 1 Discourse | 2026-06-17 | N/A | 3.5 LOW |
| Discourse is an open-source discussion platform. Prior to version 2.9.0.beta13, users can post chat messages of an unlimited length, which can cause a denial of service for other users when posting huge amounts of text. Users should upgrade to version 2.9.0.beta13, where a limit has been introduced. No known workarounds are available. | |||||
| CVE-2022-41846 | 1 Axiosys | 1 Bento4 | 2026-06-17 | N/A | 5.5 MEDIUM |
| An issue was discovered in Bento4 1.6.0-639. There ie excessive memory consumption in the function AP4_DataBuffer::ReallocateBuffer in Core/Ap4DataBuffer.cpp. | |||||
| CVE-2022-41845 | 1 Axiosys | 1 Bento4 | 2026-06-17 | N/A | 5.5 MEDIUM |
| An issue was discovered in Bento4 1.6.0-639. There ie excessive memory consumption in the function AP4_Array<AP4_ElstEntry>::EnsureCapacity in Core/Ap4Array.h. | |||||
| CVE-2022-41727 | 2 Fedoraproject, Golang | 3 Fedora, Image, Tiff | 2026-06-17 | N/A | 5.5 MEDIUM |
| An attacker can craft a malformed TIFF image which will consume a significant amount of memory when passed to DecodeConfig. This could lead to a denial of service. | |||||
| CVE-2022-41725 | 1 Golang | 1 Go | 2026-06-17 | 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-41717 | 2 Fedoraproject, Golang | 3 Fedora, Go, Http2 | 2026-06-17 | N/A | 5.3 MEDIUM |
| An attacker can cause excessive memory growth in a Go server accepting HTTP/2 requests. HTTP/2 server connections contain a cache of HTTP header keys sent by the client. While the total number of entries in this cache is capped, an attacker sending very large keys can cause the server to allocate approximately 64 MiB per open connection. | |||||
| CVE-2022-41288 | 1 Siemens | 2 Jt2go, Teamcenter Visualization | 2026-06-17 | N/A | 3.3 LOW |
| A vulnerability has been identified in JT2Go (All versions < V14.1.0.6), Teamcenter Visualization V13.2 (All versions < V13.2.0.12), Teamcenter Visualization V13.3 (All versions < V13.3.0.8), Teamcenter Visualization V14.0 (All versions < V14.0.0.4), Teamcenter Visualization V14.1 (All versions < V14.1.0.6). The CGM_NIST_Loader.dll contains stack exhaustion vulnerability when parsing a CGM file. An attacker could leverage this vulnerability to crash the application causing denial of service condition. | |||||
| CVE-2022-40885 | 1 Axiosys | 1 Bento4 | 2026-06-17 | N/A | 5.5 MEDIUM |
| Bento4 v1.6.0-639 has a memory allocation issue that can cause denial of service. | |||||
| CVE-2022-40762 | 1 Samsung | 1 Mtower | 2026-06-17 | N/A | 7.5 HIGH |
| A Memory Allocation with Excessive Size Value vulnerablity in the TEE_Realloc function in Samsung mTower through 0.3.0 allows a trusted application to trigger a Denial of Service (DoS) by invoking the function TEE_Realloc with an excessive number for the parameter len. | |||||
| CVE-2022-3480 | 1 Phoenixcontact | 62 Fl Mguard Centerport, Fl Mguard Centerport Firmware, Fl Mguard Centerport Vpn-1000 and 59 more | 2026-06-17 | N/A | 7.5 HIGH |
| A remote, unauthenticated attacker could cause a denial-of-service of PHOENIX CONTACT FL MGUARD and TC MGUARD devices below version 8.9.0 by sending a larger number of unauthenticated HTTPS connections originating from different source IP’s. Configuring firewall limits for incoming connections cannot prevent the issue. | |||||
| CVE-2022-3456 | 1 Ikus-soft | 1 Rdiffweb | 2026-06-17 | N/A | 9.8 CRITICAL |
| Allocation of Resources Without Limits or Throttling in GitHub repository ikus060/rdiffweb prior to 2.5.0. | |||||
| CVE-2022-3439 | 1 Ikus-soft | 1 Rdiffweb | 2026-06-17 | N/A | 9.8 CRITICAL |
| Allocation of Resources Without Limits or Throttling in GitHub repository ikus060/rdiffweb prior to 2.5.0. | |||||
| CVE-2022-3423 | 1 Nocodb | 1 Nocodb | 2026-06-17 | N/A | 7.3 HIGH |
| Allocation of Resources Without Limits or Throttling in GitHub repository nocodb/nocodb prior to 0.92.0. | |||||
| CVE-2022-3371 | 1 Ikus-soft | 1 Rdiffweb | 2026-06-17 | N/A | 7.5 HIGH |
| Allocation of Resources Without Limits or Throttling in GitHub repository ikus060/rdiffweb prior to 2.5.0a3. | |||||
| CVE-2022-3364 | 1 Ikus-soft | 1 Rdiffweb | 2026-06-17 | N/A | 7.5 HIGH |
| Allocation of Resources Without Limits or Throttling in GitHub repository ikus060/rdiffweb prior to 2.5.0a3. | |||||
| CVE-2022-3298 | 1 Ikus-soft | 1 Rdiffweb | 2026-06-17 | N/A | 7.5 HIGH |
| Allocation of Resources Without Limits or Throttling in GitHub repository ikus060/rdiffweb prior to 2.4.8. | |||||
| CVE-2022-3295 | 1 Ikus-soft | 1 Rdiffweb | 2026-06-17 | N/A | 7.5 HIGH |
| Allocation of Resources Without Limits or Throttling in GitHub repository ikus060/rdiffweb prior to 2.4.8. | |||||
| CVE-2022-3273 | 1 Ikus-soft | 1 Rdiffweb | 2026-06-17 | N/A | 9.8 CRITICAL |
| Allocation of Resources Without Limits or Throttling in GitHub repository ikus060/rdiffweb prior to 2.5.0a4. | |||||
| CVE-2022-3212 | 1 Axum-core Project | 1 Axum-core | 2026-06-17 | N/A | 7.5 HIGH |
| <bytes::Bytes as axum_core::extract::FromRequest>::from_request would not, by default, set a limit for the size of the request body. That meant if a malicious peer would send a very large (or infinite) body your server might run out of memory and crash. This also applies to these extractors which used Bytes::from_request internally: axum::extract::Form axum::extract::Json String | |||||
| CVE-2022-3147 | 1 Mattermost | 1 Mattermost Server | 2026-06-17 | N/A | 3.1 LOW |
| Mattermost version 7.0.x and earlier fails to sufficiently limit the in-memory sizes of concurrently uploaded JPEG images, which allows authenticated users to cause resource exhaustion on specific system configurations, resulting in server-side Denial of Service. | |||||