| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| MariaDB Connector/J is used to connect applications developed in Java to MariaDB and MySQL databases. From 3.0.0 until 3.3.7, 3.4.5, and 3.5.11, the MariaDbPoolConnection.recover() and MariaDbPoolPinnedConnection.recover() implementations trusted the gtrid_length and bqual_length columns returned by XA RECOVER. The methods allocated and split Xid byte arrays without validating the lengths against Xid.MAXGTRIDSIZE, Xid.MAXBQUALSIZE, or the actual data payload. A malicious or compromised server, or a machine-in-the-middle attacker, could cause large allocations, NegativeArraySizeException, or ArrayIndexOutOfBoundsException during XA recovery. This issue is fixed in versions 3.3.7, 3.4.5, and 3.5.11. |
| MariaDB Connector/J is used to connect applications developed in Java to MariaDB and MySQL databases. From 3.0.0 until 3.3.7, 3.4.5, and 3.5.11, when CLIENT_SESSION_TRACK was negotiated, the OkPacket.parse() and OkPacket.parseWithInfo() paths allocated byte arrays using server-declared lengths for the OK packet info field and session-state variable names and values before confirming that the bytes remained in the packet. A malicious or compromised server, or a machine-in-the-middle attacker, could send a small OK packet declaring a much larger length and repeatedly force attacker-controlled heap allocations before the subsequent copy failed. This could create garbage-collection pressure or an OutOfMemoryError in the client application. This issue is fixed in versions 3.3.7, 3.4.5, and 3.5.11. |
| MariaDB Connector/J is used to connect applications developed in Java to MariaDB and MySQL databases. From 3.0.0 until 3.3.7 and 3.4.5, during caching_sha2_password authentication, the authentication-more-data response was treated as a length-encoded byte array, memory was allocated from the server-declared length, and authResult[0] was accessed without ensuring a byte existed. A malicious or compromised server, or a machine-in-the-middle attacker, could declare a very large length or send an empty response before any password was transmitted. The malformed packet could cause excessive allocation or an unchecked ArrayIndexOutOfBoundsException escaping from DriverManager.getConnection(). This issue is fixed in versions 3.3.7 and 3.4.5. |
| zip is a zip library for Rust that supports reading and writing simple ZIP files. From 5.1.0 until 9.0.0, applications built with the legacy-zip feature can reserve output capacity from an attacker-controlled ZIP64 uncompressed size before validating the compressed stream. The ShrinkDecoder path in src/legacy/shrink.rs can panic with a capacity overflow during ZipArchive::extract, and the Reduce and Implode decoders contain the same unbounded preallocation pattern. An unhandled panic can terminate an archive-processing service. This issue is fixed in version 9.0.0. |
| The RTMP AMF parser in Apache bRPC accepts AMF string lengths and array counts directly from untrusted input. A remote unauthenticated attacker who can reach a bRPC server with RTMP enabled can send a small AMF payload with an excessive declared long string length or array count, causing excessive memory allocation or resource consumption before the parser rejects the incomplete payload.
Root Cause:
The AMF long string parser resized the destination string to the declared 32-bit length before validating that the stream contained that many bytes. ECMA array and strict array parsers also accepted 32-bit element counts without a configurable upper bound.
Affected Scenarios:
Deployments that enable the bRPC RTMP server component and accept RTMP traffic from untrusted clients. Direct uses of the AMF parser on untrusted data are also affected.
How to Fix:
1. Upgrade bRPC to version 1.18.0, which fixes this issue.
2. Apply this patch: https://github.com/apache/brpc/pull/3353
Note:
The fix introduces configurable AMF parsing limits. The default maximum string size is 64 MiB and the default maximum array element count is 1,048,576. Payloads above these limits are rejected. The limits can be adjusted with amf_max_string_size and amf_max_array_size. |
| A weakness has been identified in nschloe meshio up to 5.3.5. Impacted is an unknown function of the file meshio/_vtk_42.py of the component VTK Reader. Executing a manipulation of the argument DIMENSIONS can lead to uncontrolled memory allocation. The attack can be executed remotely. The project was informed of the problem early through an issue report but has not responded yet. |
| A vulnerability was identified in smg-project smg 1.7.0/1.8.0/1.9.0/1.10.0/1.10.1. Affected is the function jpeg_turbo::decode_jpeg_rgb of the file crates/multimodal/src/jpeg_turbo.rs of the component llm-multimodal. The manipulation leads to uncontrolled memory allocation. The attack can be initiated remotely. The exploit is publicly available and might be used. Upgrading to version 1.11.0 is able to address this issue. The identifier of the patch is 8f51b57e219a914089e345b704c3c8de37a3bb8e. It is advisable to upgrade the affected component. |
| PhpSpreadsheet is a pure PHP library for reading and writing spreadsheet files. Prior to 1.30.7, 2.1.19, 2.4.8, 3.10.8, and 5.10.0, Ods::processTableRow in src/PhpSpreadsheet/Reader/Ods.php accepts an unbounded table:number-rows-repeated attribute from an ODS table row. When the row contains a value, the reader materializes a cell for every repetition without checking the spreadsheet row limit, so a small attacker-controlled ODS file can consume substantial CPU and memory and terminate the PHP worker. Column repetition is separately bounded and is not part of this vulnerability. This issue is fixed in versions 1.30.7, 2.1.19, 2.4.8, 3.10.8, and 5.10.0. |
| Memory allocation with excessive size value in the MQTT 3.1.1 compatibility adapter in AWS aws-c-mqtt before 0.16.2 might allow a remote actor to cause a denial of service of the client application.
To remediate this issue, users should upgrade to aws-c-mqtt 0.16.2 or later, or to an AWS Common Runtime or AWS IoT Device SDK release that bundles it. |
| Pillow is a Python imaging library. From 8.1.0 until 13.0.0, Pillow can allocate an APNG disposal background at the full canvas size before applying the decompression-bomb check. A crafted APNG with a small first frame, a very large declared canvas, and background disposal or first-frame OP_PREVIOUS reaches PngImageFile._seek while Image.open() positions frame zero. The full-canvas allocation occurs inside Image.open() without requiring pixel loading or frame iteration. This can exhaust memory and deny service. This issue is fixed in version 13.0.0. |
| Memory allocation with excessive size value in the HSS/LMS signature code (HssPublicKeyParameters, HssSignature) in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 allows a remote unauthenticated attacker who can supply both an HSS public key and a signature to cause a denial of service through memory exhaustion via a public key encoding with an excessive level count, because the level count L read when parsing an HSS public key was not checked against the RFC 8554 maximum of 8, and signature parsing then allocated an array of L - 1 entries before reading any further signature data. A single verification can commit up to about 17 GB of memory or fail with an OutOfMemoryException. |
| Memory allocation with excessive size value in the OpenPGP signature and user attribute subpacket parsers (SignatureSubpacketsParser.ReadPacket, UserAttributeSubpacketsParser.ReadPacket) in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 allows a remote, unauthenticated attacker who can supply a crafted OpenPGP public key, certificate or signature to cause a denial of service (OutOfMemoryException or memory exhaustion in the parsing process) via a subpacket header using the five-octet length form, because the declared length was used to size the subpacket buffer with no upper bound and without being compared with the size of the enclosing subpacket area or packet, so a few bytes of input could demand an allocation of up to about 2 GB before any subpacket data was read. |
| Memory allocation with excessive size value in the DTLS handshake reassembly (DtlsReliableHandshake, DtlsReassembler) in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 allows a remote unauthenticated DTLS peer to cause a denial of service through memory exhaustion via crafted handshake message fragments, because the reassembly buffer for each incoming handshake message was allocated at the 24-bit length declared in the fragment header, without the check against the peer's maximum handshake message size that TLS already applied. A fragment carrying no payload can force an allocation of almost 16 MB, for each of up to 16 pending messages per handshake, before the handshake is authenticated. DTLS servers and DTLS clients are both affected; TLS is not. |
| zip is a zip library for Rust that supports reading and writing simple ZIP files. From 1.3.0 until 9.0.0, ZipArchive::extract in src/read/mod.rs calls Vec::with_capacity for a symbolic link target using the attacker-controlled ZIP64 uncompressed_size before reading entry data. A small archive can request an impossible capacity, causing the infallible allocation path to abort the process before the entry is validated. The failure cannot be contained with catch_unwind or a worker thread, allowing repeated denial of service in archive-processing applications. This issue is fixed in version 9.0.0. |
| ImageSharp is a 2D graphics library. From 1.0.0-beta0001 until 4.1.2, ICC CLUT parsing calculates allocation sizes from attacker-declared channel and grid dimensions before confirming that the profile contains the declared values. IccDataReader.ReadClutF32 can request a large float array, and earlier public IccProfile.Entries parsing paths can allocate a large jagged representation, from a short truncated profile. In version 4, automatic image conversion reaches the parser when DecoderOptions.ColorProfileHandling is Convert; the default Preserve mode avoids that conversion path. The demonstrated impact is memory pressure and input-validation failure, not unhandled process termination. This issue is fixed in version 4.1.2. |
| Ghidra through 12.2 contains an uncontrolled memory allocation vulnerability in BinaryField.read() that allows attackers to exhaust heap memory via an unchecked 32-bit length field. Attackers can persuade users to import a crafted GZF packed database file, triggering an OutOfMemoryError in PackedDatabase.open() that aborts the import and denies service. |
| Ghidra 10.2 through 12.1.4 contains a denial of service vulnerability in the ELF loader's ElfHeader class that allocates arrays sized by unvalidated extended section and program header counts. Attackers can supply a crafted 128-byte ELF file that triggers an OutOfMemoryError during load-spec discovery at import or in headless analysis pipelines. |
| VideoLAN libbluray through 1.5.1 contains an uncontrolled memory allocation vulnerability in _parse_extent_start_points() in clpi_parse.c that trusts the num_point field without bounds checking. Attackers can supply a crafted .clpi file on a disc, image, or directory with a huge num_point to exhaust memory and CPU, causing denial of service. |
| ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to 7.1.2-32, missing validation and resource checks in the ASE decoder allow a crafted ASE image to cause a crash or a long-running operation. This issue is fixed in version 7.1.2-32. |
| libspatialite through 5.1.0 fails to validate the polygon ring count in ParseWkbPolygon, allowing attackers to trigger uncontrolled interior-ring allocation via crafted geometry BLOBs. Attackers can supply a crafted polygon in a SpatiaLite database or ST_GeomFromWKB input to crash the process or corrupt heap memory on 32-bit builds. |
