yawkat LZ4 Java provides LZ4 compression for Java. Prior to 1.11.2, LZ4DecompressorWithLength uses getDecompressedLength to trust the four-byte decompressed-length header before validating the compressed input, allowing a five-byte attacker-supplied input whose header declares a large output size to request up to approximately 2 GiB and exhaust the JVM heap. Convenience overloads backed by LZ4FastDecompressor or LZ4SafeDecompressor allocate the untrusted size, while overloads that write to a caller-provided destination buffer are not affected because the caller controls the destination size. This issue is fixed in version 1.11.2.
CVE-2026-103005 is a medium severity vulnerability in Elasticsearch involving excessive memory allocation. An authenticated user with connector management privileges can create connector resources with an excessively large description field, causing the cluster to allocate uncontrolled amounts of memory. This can exhaust heap memory and crash affected nodes, resulting in a denial of service condition.
CVE-2026-106114 is a medium severity vulnerability in SixLabors.ImageSharp affecting versions from 1.0.0-beta0001 through 4.1.1. It involves a memory allocation flaw triggered by a malformed embedded ICC profile, which causes the library to allocate an excessively large amount of memory before validating the profile data. This can lead to significant memory pressure but does not cause unhandled crashes or data corruption. The issue occurs during ICC profile decoding when color profile conversion is enabled. No active exploitation is known, and the allocation failure is caught by the library.
An issue was discovered in Django 6.1 before 6.1.2, 6.0 before 6.0.9, and 5.2 before 5.2.18.
`django.utils.translation.get_supported_language_variant()` is subject to
a potential denial-of-service attack when processing many distinct, very long
language codes, which are retained as keys in an in-memory cache and
consume process memory.
Earlier, unsupported Django series (such as 5.1.x, 5.0.x, and 4.2.x) were not evaluated and may also be affected.
Django would like to thank Gleb Lizunov for reporting this issue.
CVE-2026-105749 is an uncontrolled resource consumption vulnerability in the docling-project's docling software. Versions from 2.0.0 up to but not including 2.131.0 allow HTML, JATS, OpenDocument spreadsheet, and BoxNote backends to accept rowspan and colspan attribute values without upper bounds. This can cause excessive CPU usage or multi-gigabyte memory allocation when processing small documents. The document_timeout setting does not interrupt the backend conversion call, exacerbating the impact. The issue is fixed in version 2.131.0.
CVE-2026-93323 is a medium severity vulnerability in moby BuildKit where the Dockerfile frontend loads Dockerfile and .dockerignore files into memory without size limits. This can cause excessive memory allocation if a build context contains an oversized file, potentially exhausting memory and terminating the buildkitd daemon, disrupting other builds. The issue affects versions up to 0.33.0 and is fixed by rejecting files larger than 16 MiB.
Memory allocation with excessive size value, Improper handling of length parameter inconsistency vulnerability in Apache Thrift
nodejs and D lang bindings.
Both bindings' WebSocket server transports read the payload length out of the frame header and allocate that many bytes immediately, without checking that the bytes have arrived. A single ~14-byte frame therefore commits as much memory as it cares to declare -- measured at 513 MiB against the Node.js server and 2 GiB against the D transport -- and in the Node.js case the connection is left open afterwards, so the frame can simply be sent again.
This issue affects Apache Thrift before 0.25.0.
Users are recommended to upgrade to version 0.25.0, which fixes the issue.
CVE-2026-82458 is a high-severity vulnerability in Apache Thrift before version 0.25.0 involving memory allocation with an excessive size value. This flaw affects multiple language bindings including Go, netstd, OCaml, Erlang, JavaME, Rust, C++, Java, Kotlin, and D. The issue allows allocation of resources without limits or throttling, potentially leading to resource exhaustion. The vulnerability is fixed in Apache Thrift version 0.25.0.
CVE-2026-85494 is a high-severity vulnerability in Apache Thrift affecting versions before 0.25.0. It involves improper handling of length parameter inconsistencies leading to uncaught exceptions, inefficient algorithmic complexity, excessive memory allocation, and insecure resource initialization across multiple language bindings. The issue is fixed in version 0.25.0.
CVE-2026-94633 is a high-severity vulnerability in Apache Thrift before version 0.25.0 affecting the Dart bindings. It involves improper handling of length parameters leading to memory allocation with an excessive size value. This flaw can cause memory-related issues such as crashes or potential denial of service. The issue is fixed in Apache Thrift version 0.25.0.
CVE-2026-102731 is a high-severity vulnerability in Apache Directory LDAP API versions 1.2.0 up to but not including 1.2.9. It involves memory allocation with an excessive size value triggered by a malicious BER-encoded response, leading to an OutOfMemoryError and denial of service. The issue allows an attacker to exhaust the client JVM heap with a small number of connections. The vulnerability is fixed in version 1.2.9.
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.
CVE-2026-63574 is a high-severity vulnerability in Legion of the Bouncy Castle Inc.'s bc-csharp library before version 2.7.0. It involves memory allocation with an excessive size value in the OpenPGP signature and user attribute subpacket parsers. An unauthenticated remote attacker can supply a crafted OpenPGP public key, certificate, or signature that triggers a denial of service by causing an OutOfMemoryException or memory exhaustion during parsing. This occurs because the parser uses the declared length from a subpacket header to allocate memory without upper bounds or validation against the enclosing packet size, potentially requesting up to about 2 GB of memory. The vulnerability affects all versions from 0 up to but not including 2.7.0.
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.
CVE-2026-42528 is a medium severity vulnerability in Apache HTTP Server up to version 2.4.68. It is caused by a memory allocation bug in the mod_dav module that allows an attacker with permission to create WebDAV locks to crash server child processes. The vulnerability is fixed in version 2.4.69.
CVE-2026-102504 affects Imager for Perl versions before 1.037. The vulnerability arises from improper handling of the raw_datachannels value in the i_readraw_wiol function, which lacks range checking. This can cause the program to request an excessive memory allocation, leading to process termination via an uncatchable exit call when allocation fails.
Integer Overflow, Improper Validation of Array Index, Uncontrolled Recursion and Memory Allocation with Excessive Size Value in the Go implementation of Apache PLC4X (PLC4Go) allow a malicious device, or an attacker able to inject network traffic, to crash or exhaust the memory of the client application,
causing a denial of service.
The individual defects are:
- Generated parsers pre-allocate arrays with the element count claimed on the wire (0.13.0 through 0.13.1).
- Transport read helpers allocate buffers of the size claimed on the wire without an upper bound.
- ADS and KNXnet/IP response handling indexes into received data without checking its length, causing a panic.
- ADS and EIP frame-length handling accepts, or arithmetically wraps to, a length of zero, breaking message framing.
- Recursive protocol types are parsed without a nesting-depth limit. The same defect in the Java implementation is covered by CVE-2026-102509 https://cveprocess.apache.org/cve5/CVE-2026-102509 .
Additionally, length and position arithmetic in generated serializers was performed in 16-bit integers. If an application forwards attacker-influenced payloads larger than 8 KB, the length field wraps, and the remainder of the payload may be interpreted by the receiving device (for example, an ADS PLC) as
additional, independent protocol messages.
This issue affects Apache PLC4X: from 0.11.0 before 1.0.0. PLC4Go is consumed as the Go module github.com/apache/plc4x/plc4go; versions refer to the corresponding Apache PLC4X releases.
Users are recommended to upgrade to version 1.0.0, which fixes the issue.