Total
540 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2023-20047 | 1 Cisco | 5 Sip Ip Phone Software, Webex Room Phone, Webex Room Phone Firmware and 2 more | 2023-01-31 | N/A | 6.5 MEDIUM |
| A vulnerability in the Link Layer Discovery Protocol (LLDP) feature of Cisco Webex Room Phone and Cisco Webex Share devices could allow an unauthenticated, adjacent attacker to cause a denial of service (DoS) condition on an affected device. This vulnerability is due to insufficient resource allocation. An attacker could exploit this vulnerability by sending crafted LLDP traffic to an affected device. A successful exploit could allow the attacker to exhaust the memory resources of the affected device, resulting in a crash of the LLDP process. If the affected device is configured to support LLDP only, this could cause an interruption to inbound and outbound calling. By default, these devices are configured to support both Cisco Discovery Protocol and LLDP. To recover operational state, the affected device needs a manual restart. | |||||
| CVE-2021-36630 | 1 Ruckuswireless | 8 Sz-100, Sz-100 Firmware, Sz-144 and 5 more | 2023-01-31 | N/A | 7.5 HIGH |
| DDOS reflection amplification vulnerability in eAut module of Ruckus Wireless SmartZone controller that allows remote attackers to perform DOS attacks via crafted request. | |||||
| CVE-2020-8552 | 2 Fedoraproject, Kubernetes | 2 Fedora, Kubernetes | 2023-01-27 | 4.0 MEDIUM | 4.3 MEDIUM |
| The Kubernetes API server component in versions prior to 1.15.9, 1.16.0-1.16.6, and 1.17.0-1.17.2 has been found to be vulnerable to a denial of service attack via successful API requests. | |||||
| CVE-2020-8551 | 2 Fedoraproject, Kubernetes | 2 Fedora, Kubernetes | 2023-01-27 | 3.3 LOW | 6.5 MEDIUM |
| The Kubelet component in versions 1.15.0-1.15.9, 1.16.0-1.16.6, and 1.17.0-1.17.2 has been found to be vulnerable to a denial of service attack via the kubelet API, including the unauthenticated HTTP read-only API typically served on port 10255, and the authenticated HTTPS API typically served on port 10250. | |||||
| CVE-2023-22397 | 1 Juniper | 2 Junos Os Evolved, Ptx10003 | 2023-01-24 | N/A | 6.1 MEDIUM |
| An Allocation of Resources Without Limits or Throttling weakness in the memory management of the Packet Forwarding Engine (PFE) on Juniper Networks Junos OS Evolved PTX10003 Series devices allows an adjacently located attacker who has established certain preconditions and knowledge of the environment to send certain specific genuine packets to begin a Time-of-check Time-of-use (TOCTOU) Race Condition attack which will cause a memory leak to begin. Once this condition begins, and as long as the attacker is able to sustain the offending traffic, a Distributed Denial of Service (DDoS) event occurs. As a DDoS event, the offending packets sent by the attacker will continue to flow from one device to another as long as they are received and processed by any devices, ultimately causing a cascading outage to any vulnerable devices. Devices not vulnerable to the memory leak will process and forward the offending packet(s) to neighboring devices. Due to internal anti-flood security controls and mechanisms reaching their maximum limit of response in the worst-case scenario, all affected Junos OS Evolved devices will reboot in as little as 1.5 days. Reboots to restore services cannot be avoided once the memory leak begins. The device will self-recover after crashing and rebooting. Operator intervention isn't required to restart the device. This issue affects: Juniper Networks Junos OS Evolved on PTX10003: All versions prior to 20.4R3-S4-EVO; 21.3 versions prior to 21.3R3-S1-EVO; 21.4 versions prior to 21.4R2-S2-EVO, 21.4R3-EVO; 22.1 versions prior to 22.1R1-S2-EVO, 22.1R2-EVO; 22.2 versions prior to 22.2R2-EVO. To check memory, customers may VTY to the PFE first then execute the following show statement: show jexpr jtm ingress-main-memory chip 255 | no-more Alternatively one may execute from the RE CLI: request pfe execute target fpc0 command "show jexpr jtm ingress-main-memory chip 255 | no-more" Iteration 1: Example output: Mem type: NH, alloc type: JTM 136776 bytes used (max 138216 bytes used) 911568 bytes available (909312 bytes from free pages) Iteration 2: Example output: Mem type: NH, alloc type: JTM 137288 bytes used (max 138216 bytes used) 911056 bytes available (909312 bytes from free pages) The same can be seen in the CLI below, assuming the scale does not change: show npu memory info Example output: FPC0:NPU16 mem-util-jnh-nh-size 2097152 FPC0:NPU16 mem-util-jnh-nh-allocated 135272 FPC0:NPU16 mem-util-jnh-nh-utilization 6 | |||||
| CVE-2022-20751 | 1 Cisco | 23 Firepower 1000, Firepower 1010, Firepower 1020 and 20 more | 2023-01-24 | 7.1 HIGH | 7.5 HIGH |
| A vulnerability in the Snort detection engine integration for Cisco Firepower Threat Defense (FTD) Software could allow an unauthenticated, remote attacker to cause unlimited memory consumption, which could lead to a denial of service (DoS) condition on an affected device. This vulnerability is due to insufficient memory management for certain Snort events. An attacker could exploit this vulnerability by sending a series of crafted IP packets that would generate specific Snort events on an affected device. A sustained attack could cause an out of memory condition on the affected device. A successful exploit could allow the attacker to interrupt all traffic flowing through the affected device. In some circumstances, the attacker may be able to cause the device to reload, resulting in a DoS condition. | |||||
| CVE-2017-11468 | 2 Docker, Redhat | 2 Docker Registry, Enterprise Linux Server | 2023-01-20 | 5.0 MEDIUM | 7.5 HIGH |
| Docker Registry before 2.6.2 in Docker Distribution does not properly restrict the amount of content accepted from a user, which allows remote attackers to cause a denial of service (memory consumption) via the manifest endpoint. | |||||
| CVE-2023-22403 | 1 Juniper | 4 Junos, Qfx10002, Qfx10008 and 1 more | 2023-01-19 | N/A | 7.5 HIGH |
| An Allocation of Resources Without Limits or Throttling vulnerability in the Packet Forwarding Engine (PFE) of Juniper Networks Junos OS allows a network-based, unauthenticated attacker to cause a Denial of Service (DoS). On QFX10k Series Inter-Chassis Control Protocol (ICCP) is used in MC-LAG topologies to exchange control information between the devices in the topology. ICCP connection flaps and sync issues will be observed due to excessive specific traffic to the local device. This issue affects Juniper Networks Junos OS: All versions prior to 20.2R3-S7; 20.4 versions prior to 20.4R3-S4; 21.1 versions prior to 21.1R3-S3; 21.2 versions prior to 21.2R3-S1; 21.3 versions prior to 21.3R3; 21.4 versions prior to 21.4R3; 22.1 versions prior to 22.1R2. | |||||
| CVE-2019-9517 | 12 Apache, Apple, Canonical and 9 more | 25 Http Server, Traffic Server, Mac Os X and 22 more | 2023-01-19 | 7.8 HIGH | 7.5 HIGH |
| Some HTTP/2 implementations are vulnerable to unconstrained interal data buffering, potentially leading to a denial of service. The attacker opens the HTTP/2 window so the peer can send without constraint; however, they leave the TCP window closed so the peer cannot actually write (many of) the bytes on the wire. The attacker then sends a stream of requests for a large response object. Depending on how the servers queue the responses, this can consume excess memory, CPU, or both. | |||||
| CVE-2020-36568 | 1 Revel | 1 Revel | 2023-01-05 | N/A | 7.5 HIGH |
| Unsanitized input in the query parser in github.com/revel/revel before v1.0.0 allows remote attackers to cause resource exhaustion via memory allocation. | |||||
| CVE-2022-32205 | 6 Apple, Debian, Fedoraproject and 3 more | 28 Macos, Debian Linux, Fedora and 25 more | 2023-01-05 | 4.3 MEDIUM | 4.3 MEDIUM |
| A malicious server can serve excessive amounts of `Set-Cookie:` headers in a HTTP response to curl and curl < 7.84.0 stores all of them. A sufficiently large amount of (big) cookies make subsequent HTTP requests to this, or other servers to which the cookies match, create requests that become larger than the threshold that curl uses internally to avoid sending crazy large requests (1048576 bytes) and instead returns an error.This denial state might remain for as long as the same cookies are kept, match and haven't expired. Due to cookie matching rules, a server on `foo.example.com` can set cookies that also would match for `bar.example.com`, making it it possible for a "sister server" to effectively cause a denial of service for a sibling site on the same second level domain using this method. | |||||
| CVE-2022-4723 | 1 Ikus-soft | 1 Rdiffweb | 2023-01-05 | N/A | 6.5 MEDIUM |
| Allocation of Resources Without Limits or Throttling in GitHub repository ikus060/rdiffweb prior to 2.5.5. | |||||
| CVE-2022-42531 | 1 Google | 1 Android | 2022-12-21 | N/A | 7.8 HIGH |
| In mmu_map_for_fw of gs_ldfw_load.c, there is a possible mitigation bypass due to Permissive Memory Allocation. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android kernelAndroid ID: A-231500967References: N/A | |||||
| CVE-2022-22488 | 1 Ibm | 6 Power System Ac922 \(8335-gtg\), Power System Ac922 \(8335-gtg\) Firmware, Power System Ac922 \(8335-gth\) and 3 more | 2022-12-13 | N/A | 4.9 MEDIUM |
| IBM OpenBMC OP910 and OP940 could allow a privileged user to cause a denial of service by uploading or deleting too many CA certificates in a short period of time. IBM X-Force ID: 2226337. | |||||
| CVE-2022-42316 | 3 Debian, Fedoraproject, Xen | 3 Debian Linux, Fedora, Xen | 2022-12-12 | N/A | 6.5 MEDIUM |
| Xenstore: guests can let run xenstored out of memory T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Malicious guests can cause xenstored to allocate vast amounts of memory, eventually resulting in a Denial of Service (DoS) of xenstored. There are multiple ways how guests can cause large memory allocations in xenstored: - - by issuing new requests to xenstored without reading the responses, causing the responses to be buffered in memory - - by causing large number of watch events to be generated via setting up multiple xenstore watches and then e.g. deleting many xenstore nodes below the watched path - - by creating as many nodes as allowed with the maximum allowed size and path length in as many transactions as possible - - by accessing many nodes inside a transaction | |||||
| CVE-2022-42315 | 3 Debian, Fedoraproject, Xen | 3 Debian Linux, Fedora, Xen | 2022-12-12 | N/A | 6.5 MEDIUM |
| Xenstore: guests can let run xenstored out of memory T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Malicious guests can cause xenstored to allocate vast amounts of memory, eventually resulting in a Denial of Service (DoS) of xenstored. There are multiple ways how guests can cause large memory allocations in xenstored: - - by issuing new requests to xenstored without reading the responses, causing the responses to be buffered in memory - - by causing large number of watch events to be generated via setting up multiple xenstore watches and then e.g. deleting many xenstore nodes below the watched path - - by creating as many nodes as allowed with the maximum allowed size and path length in as many transactions as possible - - by accessing many nodes inside a transaction | |||||
| CVE-2022-42313 | 3 Debian, Fedoraproject, Xen | 3 Debian Linux, Fedora, Xen | 2022-12-12 | N/A | 6.5 MEDIUM |
| Xenstore: guests can let run xenstored out of memory T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Malicious guests can cause xenstored to allocate vast amounts of memory, eventually resulting in a Denial of Service (DoS) of xenstored. There are multiple ways how guests can cause large memory allocations in xenstored: - - by issuing new requests to xenstored without reading the responses, causing the responses to be buffered in memory - - by causing large number of watch events to be generated via setting up multiple xenstore watches and then e.g. deleting many xenstore nodes below the watched path - - by creating as many nodes as allowed with the maximum allowed size and path length in as many transactions as possible - - by accessing many nodes inside a transaction | |||||
| CVE-2022-42312 | 3 Debian, Fedoraproject, Xen | 3 Debian Linux, Fedora, Xen | 2022-12-12 | N/A | 6.5 MEDIUM |
| Xenstore: guests can let run xenstored out of memory T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Malicious guests can cause xenstored to allocate vast amounts of memory, eventually resulting in a Denial of Service (DoS) of xenstored. There are multiple ways how guests can cause large memory allocations in xenstored: - - by issuing new requests to xenstored without reading the responses, causing the responses to be buffered in memory - - by causing large number of watch events to be generated via setting up multiple xenstore watches and then e.g. deleting many xenstore nodes below the watched path - - by creating as many nodes as allowed with the maximum allowed size and path length in as many transactions as possible - - by accessing many nodes inside a transaction | |||||
| CVE-2022-41717 | 1 Golang | 2 Go, Http2 | 2022-12-12 | 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-42314 | 3 Debian, Fedoraproject, Xen | 3 Debian Linux, Fedora, Xen | 2022-12-09 | N/A | 6.5 MEDIUM |
| Xenstore: guests can let run xenstored out of memory T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Malicious guests can cause xenstored to allocate vast amounts of memory, eventually resulting in a Denial of Service (DoS) of xenstored. There are multiple ways how guests can cause large memory allocations in xenstored: - - by issuing new requests to xenstored without reading the responses, causing the responses to be buffered in memory - - by causing large number of watch events to be generated via setting up multiple xenstore watches and then e.g. deleting many xenstore nodes below the watched path - - by creating as many nodes as allowed with the maximum allowed size and path length in as many transactions as possible - - by accessing many nodes inside a transaction | |||||