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. |