Filtered by CWE-770
Total 945 CVE
CVE Vendors Products Updated CVSS v3.1
CVE-2022-4045 1 Mattermost 1 Mattermost 2024-08-03 3.1 Low
A denial-of-service vulnerability in the Mattermost allows an authenticated user to crash the server via multiple requests to one of the API endpoints which could fetch a large amount of data. 
CVE-2022-4019 1 Mattermost 1 Mattermost 2024-08-03 4.3 Medium
A denial-of-service vulnerability in the Mattermost Playbooks plugin allows an authenticated user to crash the server via multiple large requests to one of the Playbooks API endpoints.
CVE-2022-4044 1 Mattermost 1 Mattermost 2024-08-03 4.3 Medium
A denial-of-service vulnerability in Mattermost allows an authenticated user to crash the server via multiple large autoresponder messages.
CVE-2022-3480 1 Phoenixcontact 62 Fl Mguard Centerport, Fl Mguard Centerport Firmware, Fl Mguard Centerport Vpn-1000 and 59 more 2024-08-03 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 2024-08-03 9.8 Critical
Allocation of Resources Without Limits or Throttling in GitHub repository ikus060/rdiffweb prior to 2.5.0.
CVE-2022-3423 1 Xgenecloud 1 Nocodb 2024-08-03 7.3 High
Allocation of Resources Without Limits or Throttling in GitHub repository nocodb/nocodb prior to 0.92.0.
CVE-2022-3439 1 Ikus-soft 1 Rdiffweb 2024-08-03 9.8 Critical
Allocation of Resources Without Limits or Throttling in GitHub repository ikus060/rdiffweb prior to 2.5.0.
CVE-2022-3364 1 Ikus-soft 1 Rdiffweb 2024-08-03 7.5 High
Allocation of Resources Without Limits or Throttling in GitHub repository ikus060/rdiffweb prior to 2.5.0a3.
CVE-2022-3371 1 Ikus-soft 1 Rdiffweb 2024-08-03 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 2024-08-03 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 2024-08-03 9.8 Critical
Allocation of Resources Without Limits or Throttling in GitHub repository ikus060/rdiffweb prior to 2.5.0a4.
CVE-2022-3295 1 Ikus-soft 1 Rdiffweb 2024-08-03 7.5 High
Allocation of Resources Without Limits or Throttling in GitHub repository ikus060/rdiffweb prior to 2.4.8.
CVE-2022-3212 1 Axum-core Project 1 Axum-core 2024-08-03 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 2024-08-03 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.
CVE-2022-2879 2 Golang, Redhat 16 Go, Container Native Virtualization, Devtools and 13 more 2024-08-03 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.
CVE-2022-2406 1 Mattermost 1 Mattermost 2024-08-03 4.3 Medium
The legacy Slack import feature in Mattermost version 6.7.0 and earlier fails to properly limit the sizes of imported files, which allows an authenticated attacker to crash the server by importing large files via the Slack import REST API.
CVE-2022-2134 1 Inventree Project 1 Inventree 2024-08-03 6.5 Medium
Allocation of Resources Without Limits or Throttling in GitHub repository inventree/inventree prior to 0.8.0.
CVE-2022-2132 4 Debian, Dpdk, Fedoraproject and 1 more 15 Debian Linux, Data Plane Development Kit, Fedora and 12 more 2024-08-03 8.6 High
A permissive list of allowed inputs flaw was found in DPDK. This issue allows a remote attacker to cause a denial of service triggered by sending a crafted Vhost header to DPDK.
CVE-2022-2053 1 Redhat 4 Integration Camel K, Jboss Enterprise Application Platform, Jboss Fuse and 1 more 2024-08-03 7.5 High
When a POST request comes through AJP and the request exceeds the max-post-size limit (maxEntitySize), Undertow's AjpServerRequestConduit implementation closes a connection without sending any response to the client/proxy. This behavior results in that a front-end proxy marking the backend worker (application server) as an error state and not forward requests to the worker for a while. In mod_cluster, this continues until the next STATUS request (10 seconds intervals) from the application server updates the server state. So, in the worst case, it can result in "All workers are in error state" and mod_cluster responds "503 Service Unavailable" for a while (up to 10 seconds). In mod_proxy_balancer, it does not forward requests to the worker until the "retry" timeout passes. However, luckily, mod_proxy_balancer has "forcerecovery" setting (On by default; this parameter can force the immediate recovery of all workers without considering the retry parameter of the workers if all workers of a balancer are in error state.). So, unlike mod_cluster, mod_proxy_balancer does not result in responding "503 Service Unavailable". An attacker could use this behavior to send a malicious request and trigger server errors, resulting in DoS (denial of service). This flaw was fixed in Undertow 2.2.19.Final, Undertow 2.3.0.Alpha2.
CVE-2022-1708 3 Fedoraproject, Kubernetes, Redhat 5 Fedora, Cri-o, Enterprise Linux and 2 more 2024-08-03 7.5 High
A vulnerability was found in CRI-O that causes memory or disk space exhaustion on the node for anyone with access to the Kube API. The ExecSync request runs commands in a container and logs the output of the command. This output is then read by CRI-O after command execution, and it is read in a manner where the entire file corresponding to the output of the command is read in. Thus, if the output of the command is large it is possible to exhaust the memory or the disk space of the node when CRI-O reads the output of the command. The highest threat from this vulnerability is system availability.