Total
1160 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2023-35116 | 1 Fasterxml | 1 Jackson-databind | 2024-11-21 | N/A | 4.7 MEDIUM |
| jackson-databind through 2.15.2 allows attackers to cause a denial of service or other unspecified impact via a crafted object that uses cyclic dependencies. NOTE: the vendor's perspective is that this is not a valid vulnerability report, because the steps of constructing a cyclic data structure and trying to serialize it cannot be achieved by an external attacker. | |||||
| CVE-2023-34994 | 1 Openautomationsoftware | 1 Oas Platform | 2024-11-21 | N/A | 3.1 LOW |
| An improper resource allocation vulnerability exists in the OAS Engine configuration management functionality of Open Automation Software OAS Platform v18.00.0072. A specially crafted series of network requests can lead to creation of an arbitrary directory. An attacker can send a sequence of requests to trigger this vulnerability. | |||||
| CVE-2023-34455 | 1 Xerial | 1 Snappy-java | 2024-11-21 | N/A | 7.5 HIGH |
| snappy-java is a fast compressor/decompressor for Java. Due to use of an unchecked chunk length, an unrecoverable fatal error can occur in versions prior to 1.1.10.1. The code in the function hasNextChunk in the fileSnappyInputStream.java checks if a given stream has more chunks to read. It does that by attempting to read 4 bytes. If it wasn’t possible to read the 4 bytes, the function returns false. Otherwise, if 4 bytes were available, the code treats them as the length of the next chunk. In the case that the `compressed` variable is null, a byte array is allocated with the size given by the input data. Since the code doesn’t test the legality of the `chunkSize` variable, it is possible to pass a negative number (such as 0xFFFFFFFF which is -1), which will cause the code to raise a `java.lang.NegativeArraySizeException` exception. A worse case would happen when passing a huge positive value (such as 0x7FFFFFFF), which would raise the fatal `java.lang.OutOfMemoryError` error. Version 1.1.10.1 contains a patch for this issue. | |||||
| CVE-2023-34450 | 1 Cometbft | 1 Cometbft | 2024-11-21 | N/A | 3.7 LOW |
| CometBFT is a Byzantine Fault Tolerant (BFT) middleware that takes a state transition machine and replicates it on many machines. An internal modification made in versions 0.34.28 and 0.37.1 to the way struct `PeerState` is serialized to JSON introduced a deadlock when new function MarshallJSON is called. This function can be called from two places. The first is via logs, setting the `consensus` logging module to "debug" level (should not happen in production), and setting the log output format to JSON. The second is via RPC `dump_consensus_state`. Case 1, which should not be hit in production, will eventually hit the deadlock in most goroutines, effectively halting the node. In case 2, only the data structures related to the first peer will be deadlocked, together with the thread(s) dealing with the RPC request(s). This means that only one of the channels of communication to the node's peers will be blocked. Eventually the peer will timeout and excluded from the list (typically after 2 minutes). The goroutines involved in the deadlock will not be garbage collected, but they will not interfere with the system after the peer is excluded. The theoretical worst case for case 2, is a network with only two validator nodes. In this case, each of the nodes only has one `PeerState` struct. If `dump_consensus_state` is called in either node (or both), the chain will halt until the peer connections time out, after which the nodes will reconnect (with different `PeerState` structs) and the chain will progress again. Then, the same process can be repeated. As the number of nodes in a network increases, and thus, the number of peer struct each node maintains, the possibility of reproducing the perturbation visible with two nodes decreases. Only the first `PeerState` struct will deadlock, and not the others (RPC `dump_consensus_state` accesses them in a for loop, so the deadlock at the first iteration causes the rest of the iterations of that "for" loop to never be reached). This regression was fixed in versions 0.34.29 and 0.37.2. Some workarounds are available. For case 1 (hitting the deadlock via logs), either don't set the log output to "json", leave at "plain", or don't set the consensus logging module to "debug", leave it at "info" or higher. For case 2 (hitting the deadlock via RPC `dump_consensus_state`), do not expose `dump_consensus_state` RPC endpoint to the public internet (e.g., via rules in one's nginx setup). | |||||
| CVE-2023-34389 | 1 Selinc | 2 Sel-451, Sel-451 Firmware | 2024-11-21 | N/A | 4.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-33953 | 1 Grpc | 1 Grpc | 2024-11-21 | N/A | 7.5 HIGH |
| gRPC contains a vulnerability that allows hpack table accounting errors could lead to unwanted disconnects between clients and servers in exceptional cases/ Three vectors were found that allow the following DOS attacks: - Unbounded memory buffering in the HPACK parser - Unbounded CPU consumption in the HPACK parser The unbounded CPU consumption is down to a copy that occurred per-input-block in the parser, and because that could be unbounded due to the memory copy bug we end up with an O(n^2) parsing loop, with n selected by the client. The unbounded memory buffering bugs: - The header size limit check was behind the string reading code, so we needed to first buffer up to a 4 gigabyte string before rejecting it as longer than 8 or 16kb. - HPACK varints have an encoding quirk whereby an infinite number of 0’s can be added at the start of an integer. gRPC’s hpack parser needed to read all of them before concluding a parse. - gRPC’s metadata overflow check was performed per frame, so that the following sequence of frames could cause infinite buffering: HEADERS: containing a: 1 CONTINUATION: containing a: 2 CONTINUATION: containing a: 3 etc… | |||||
| CVE-2023-32699 | 1 Metersphere | 1 Metersphere | 2024-11-21 | N/A | 6.5 MEDIUM |
| MeterSphere is an open source continuous testing platform. Version 2.9.1 and prior are vulnerable to denial of service. ?The `checkUserPassword` method is used to check whether the password provided by the user matches the password saved in the database, and the `CodingUtil.md5` method is used to encrypt the original password with MD5 to ensure that the password will not be saved in plain text when it is stored. If a user submits a very long password when logging in, the system will be forced to execute the long password MD5 encryption process, causing the server CPU and memory to be exhausted, thereby causing a denial of service attack on the server. This issue is fixed in version 2.10.0-lts with a maximum password length. | |||||
| CVE-2023-32481 | 1 Dell | 1 Wyse Management Suite | 2024-11-21 | N/A | 4.9 MEDIUM |
| Wyse Management Suite versions prior to 4.0 contain a denial-of-service vulnerability. An authenticated malicious user can flood the configured SMTP server with numerous requests in order to deny access to the system. | |||||
| CVE-2023-32187 | 1 K3s | 1 K3s | 2024-11-21 | N/A | 7.5 HIGH |
| An Allocation of Resources Without Limits or Throttling vulnerability in SUSE k3s allows attackers with access to K3s servers' apiserver/supervisor port (TCP 6443) cause denial of service. This issue affects k3s: from v1.24.0 before v1.24.17+k3s1, from v1.25.0 before v1.25.13+k3s1, from v1.26.0 before v1.26.8+k3s1, from sev1.27.0 before v1.27.5+k3s1, from v1.28.0 before v1.28.1+k3s1. | |||||
| CVE-2023-32186 | 1 Suse | 1 Rancher Rke2 | 2024-11-21 | N/A | 7.5 HIGH |
| A Allocation of Resources Without Limits or Throttling vulnerability in SUSE RKE2 allows attackers with access to K3s servers apiserver/supervisor port (TCP 6443) cause denial of service. This issue affects RKE2: from 1.24.0 before 1.24.17+rke2r1, from v1.25.0 before v1.25.13+rke2r1, from v1.26.0 before v1.26.8+rke2r1, from v1.27.0 before v1.27.5+rke2r1, from v1.28.0 before v1.28.1+rke2r1. | |||||
| CVE-2023-30551 | 1 Linuxfoundation | 1 Rekor | 2024-11-21 | N/A | 7.5 HIGH |
| Rekor is an open source software supply chain transparency log. Rekor prior to version 1.1.1 may crash due to out of memory (OOM) conditions caused by reading archive metadata files into memory without checking their sizes first. Verification of a JAR file submitted to Rekor can cause an out of memory crash if files within the META-INF directory of the JAR are sufficiently large. Parsing of an APK file submitted to Rekor can cause an out of memory crash if the .SIGN or .PKGINFO files within the APK are sufficiently large. The OOM crash has been patched in Rekor version 1.1.1. There are no known workarounds. | |||||
| CVE-2023-2828 | 4 Debian, Fedoraproject, Isc and 1 more | 14 Debian Linux, Fedora, Bind and 11 more | 2024-11-21 | N/A | 7.5 HIGH |
| Every `named` instance configured to run as a recursive resolver maintains a cache database holding the responses to the queries it has recently sent to authoritative servers. The size limit for that cache database can be configured using the `max-cache-size` statement in the configuration file; it defaults to 90% of the total amount of memory available on the host. When the size of the cache reaches 7/8 of the configured limit, a cache-cleaning algorithm starts to remove expired and/or least-recently used RRsets from the cache, to keep memory use below the configured limit. It has been discovered that the effectiveness of the cache-cleaning algorithm used in `named` can be severely diminished by querying the resolver for specific RRsets in a certain order, effectively allowing the configured `max-cache-size` limit to be significantly exceeded. This issue affects BIND 9 versions 9.11.0 through 9.16.41, 9.18.0 through 9.18.15, 9.19.0 through 9.19.13, 9.11.3-S1 through 9.16.41-S1, and 9.18.11-S1 through 9.18.15-S1. | |||||
| CVE-2023-2666 | 1 Froxlor | 1 Froxlor | 2024-11-21 | N/A | 7.5 HIGH |
| Allocation of Resources Without Limits or Throttling in GitHub repository froxlor/froxlor prior to 2.0.16. | |||||
| CVE-2023-29973 | 1 Pfsense | 1 Pfsense | 2024-11-21 | N/A | 4.9 MEDIUM |
| Pfsense CE version 2.6.0 is vulnerable to No rate limit which can lead to an attacker creating multiple malicious users in firewall. | |||||
| CVE-2023-29449 | 1 Zabbix | 1 Zabbix | 2024-11-21 | N/A | 5.9 MEDIUM |
| JavaScript preprocessing, webhooks and global scripts can cause uncontrolled CPU, memory, and disk I/O utilization. Preprocessing/webhook/global script configuration and testing are only available to Administrative roles (Admin and Superadmin). Administrative privileges should be typically granted to users who need to perform tasks that require more control over the system. The security risk is limited because not all users have this level of access. | |||||
| CVE-2023-29408 | 2 Fedoraproject, Golang | 2 Fedora, Image | 2024-11-21 | N/A | 6.5 MEDIUM |
| The TIFF decoder does not place a limit on the size of compressed tile data. A maliciously-crafted image can exploit this to cause a small image (both in terms of pixel width/height, and encoded size) to make the decoder decode large amounts of compressed data, consuming excessive memory and CPU. | |||||
| CVE-2023-28968 | 1 Juniper | 31 Appid Service Sigpack, Jdpi-decoder Engine, Junos and 28 more | 2024-11-21 | N/A | 5.3 MEDIUM |
| An Improperly Controlled Sequential Memory Allocation vulnerability in the Juniper Networks Deep Packet Inspection-Decoder (JDPI-Decoder) Application Signature component of Junos OS's AppID service on SRX Series devices will stop the JDPI-Decoder from identifying dynamic application traffic, allowing an unauthenticated network-based attacker to send traffic to the target device using the JDPI-Decoder, designed to inspect dynamic application traffic and take action upon this traffic, to instead begin to not take action and to pass the traffic through. An example session can be seen by running the following command and evaluating the output. user@device# run show security flow session source-prefix <address/mask> extensive Session ID: <session ID>, Status: Normal, State: Active Policy name: <name of policy> Dynamic application: junos:UNKNOWN, <<<<< LOOK HERE Please note, the JDPI-Decoder and the AppID SigPack are both affected and both must be upgraded along with the operating system to address the matter. By default, none of this is auto-enabled for automatic updates. This issue affects: Juniper Networks any version of the JDPI-Decoder Engine prior to version 5.7.0-47 with the JDPI-Decoder enabled using any version of the AppID SigPack prior to version 1.550.2-31 (SigPack 3533) on Junos OS on SRX Series: All versions prior to 19.1R3-S10; 19.2 versions prior to 19.2R3-S7; 19.3 versions prior to 19.3R3-S8; 19.4 versions prior to 19.4R3-S11; 20.1 version 20.1R1 and later versions prior to 20.2R3-S7; 20.3 version 20.3R1 and later versions prior to 20.4R3-S6; 21.1 versions prior to 21.1R3-S5; 21.2 versions prior to 21.2R3-S4; 21.3 versions prior to 21.3R3-S3; 21.4 versions prior to 21.4R3-S3; 22.1 versions prior to 22.1R3-S1; 22.2 versions prior to 22.2R2-S1, 22.2R3; 22.3 versions prior to 22.3R1-S2, 22.3R2; | |||||
| CVE-2023-28899 | 1 Skoda-auto | 2 Superb 3, Superb 3 Firmware | 2024-11-21 | N/A | 4.7 MEDIUM |
| By sending a specific reset UDS request via OBDII port of Skoda vehicles, it is possible to cause vehicle engine shutdown and denial of service of other vehicle components even when the vehicle is moving at a high speed. No safety critical functions affected. | |||||
| CVE-2023-28867 | 1 Graphql-java | 1 Graphql-java | 2024-11-21 | N/A | 7.5 HIGH |
| In GraphQL Java (aka graphql-java) before 20.1, an attacker can send a crafted GraphQL query that causes stack consumption. The fixed versions are 20.1, 19.4, 18.4, 17.5, and 0.0.0-2023-03-20T01-49-44-80e3135. | |||||
| CVE-2023-28837 | 1 Torchbox | 1 Wagtail | 2024-11-21 | N/A | 4.9 MEDIUM |
| Wagtail is an open source content management system built on Django. Prior to versions 4.1.4 and 4.2.2, a memory exhaustion bug exists in Wagtail's handling of uploaded images and documents. For both images and documents, files are loaded into memory during upload for additional processing. A user with access to upload images or documents through the Wagtail admin interface could upload a file so large that it results in a crash of denial of service. The vulnerability is not exploitable by an ordinary site visitor without access to the Wagtail admin. It can only be exploited by admin users with permission to upload images or documents. Image uploads are restricted to 10MB by default, however this validation only happens on the frontend and on the backend after the vulnerable code. Patched versions have been released as Wagtail 4.1.4 and Wagtail 4.2.2). Site owners who are unable to upgrade to the new versions are encouraged to add extra protections outside of Wagtail to limit the size of uploaded files. | |||||