msgpack-java JRuby decoder allocates from declared header counts with no cap: 5-byte message forces multi-GiB OOM

MessagePack for Ruby is an implementation of the MessagePack binary serialization format. Prior to 1.8.7, the Java-platform msgpack gem for JRuby allocated arrays and byte buffers directly from attacker-controlled array32, str32, and bin32 declared sizes before confirming that corresponding elements or bytes were available. A short MessagePack header could therefore trigger a very large allocation or sustained heap growth when an application decoded untrusted input through MessagePack.unpack or MessagePack::Unpacker, potentially exhausting the shared JVM heap. map32 and declared counts at or above 2^31 did not use the affected allocation behavior. This issue is fixed in version 1.8.7.

Unbounded memory growth with session handling in TLSv1.3

Issue summary: Some non-default TLS server configurations can cause unbounded memory growth when processing TLSv1.3 sessions Impact summary: An attacker may exploit certain server configurations to trigger unbounded memory growth that would lead to a Denial of Service This problem can occur in TLSv1.3 if the non-default SSL_OP_NO_TICKET option is being used (but not if early_data support is also configured and the default anti-replay protection is in use). In this case, under certain conditions, the session cache can get into an incorrect state and it will fail to flush properly as it fills. The session cache will continue to grow in an unbounded manner. A malicious client could deliberately create the scenario for this failure to force a Denial of Service. It may also happen by accident in normal operation. This issue only affects TLS servers supporting TLSv1.3. It does not affect TLS clients. The FIPS modules in 3.2, 3.1 and 3.0 are not affected by this issue. OpenSSL 1.0.2 is also not affected by this issue.

Smallrye-fault-tolerance: smallrye fault tolerance

A flaw was found in Smallrye, where smallrye-fault-tolerance is vulnerable to an out-of-memory (OOM) issue. This vulnerability is externally triggered when calling the metrics URI. Every call creates a new object within meterMap and may lead to a denial of service (DoS) issue.

RCE via stale global state

PHP has various global state that temporarily points into request memory. In some scenarios, global state may not be correctly reset, or may be repopulated after being reset. The global state may then refer to request memory even after it has been freed. Subsequent requests may read or branch on this stale state before it is fully initialized. Multiple strategies can trigger this condition and produce remote code execution (RCE).

RCE via OOM corruption

PHP uses longjmp() for out-of-memory (OOM) errors to exit the current context and abort handling of the request. Some contexts may not properly account for this scenario and leave request memory in an uninitialized state before performing an allocation. The subsequent request cleanup procedure may read or branch on this memory. Multiple OOM strategies can consistently trigger this condition and lead to remote code execution (RCE).

MessagePack: Nested arrays can blow past buffer length limits

MessagePack for C# is a MessagePack serializer for C#. Prior to 2.5.303 and 3.1.9, deserializing attacker-controlled MessagePack data as System.Object through PrimitiveObjectFormatter can cause excessive memory allocation. The formatter allocates an object[] from each declared array length before the configured object-graph depth limit rejects the input, while nested array headers can reuse the same trailing unread bytes to satisfy per-header length validation. A comparatively small payload can therefore keep many large arrays alive at once. When an attacker can submit such data repeatedly, the allocations can cause severe managed-heap pressure, excessive garbage collection, process termination, or loss of service. Exposure requires an application to deserialize untrusted data through the affected formatter path and permit repeated attacker-controlled submissions, such as a reachable ASP.NET Core SignalR hub method with an object parameter and AddMessagePackProtocol() enabled. This issue is fixed in versions 2.5.303 and 3.1.9.

Improperly Controlled Sequential Memory Allocation in Wireshark

USB HID protocol dissector infinite loop and memory leak in 4.6.0 to 4.6.8 and 4.4.0 to 4.4.18 allows denial of service

Improperly controlled sequential memory allocation vulnerability in Samsung Open Source rlottie allows Exponential Data Expansion.

Mermaid XY Charts are vulnerable to an infinite loop DoS

Mermaid is a JavaScript tool that uses Markdown-inspired text to create and modify diagrams and charts. From version 10.6.0 until 10.9.8 and 11.16.1, Mermaid XY Charts are vulnerable to an infinite loop denial of service in the setXAxisRangeData function when configuring an X-Axis with invalid parameters. Because each loop iteration appends an element to an array, this generally causes a RangeError to appear after a few seconds, but it may instead cause the page or JavaScript process to crash from memory exhaustion, depending on the environment. This issue is fixed in versions 10.9.8 and 11.16.1.

veraPDF Parser DoS via PostScript Type 1 Font Programs

veraPDF PDF parser is a PDF parser for veraPDF. Prior to 1.30.2 and 1.31.23, veraPDF-parser contains a denial-of-service vulnerability in veraPDF-parser/src/main/java/org/verapdf/pd/font/type1/Type1FontProgram.java and veraPDF-parser/src/main/java/org/verapdf/parser/postscript/PSOperator.java, where a crafted Type 1 font /FontDescriptor /FontFile program can execute unbounded PostScript array allocation, a zero-increment for loop, or self-recursive toExecute user dictionary lookups and exhaust validator memory, CPU, or stack. This issue is fixed in versions 1.30.2 and 1.31.23.

veraPDF Parser DoS via PostScript CMap Streams

veraPDF PDF parser is a PDF parser for veraPDF. Prior to 1.30.2 and 1.31.23, veraPDF-parser contains a denial-of-service vulnerability in veraPDF-parser/src/main/java/org/verapdf/pd/font/cmap/CMapParser.java and veraPDF-parser/src/main/java/org/verapdf/parser/postscript/PSOperator.java, where a crafted Type 0 font /Encoding or /ToUnicode CMap stream can execute unbounded PostScript array allocation or a zero-increment for loop and exhaust validator memory or CPU. This issue is fixed in versions 1.30.2 and 1.31.23.

A user with read access can cause a DoS by executing a specifically crafted query to consume a large amount of RAM

Using expressions that generate large arrays it is possible to craft a query that creates very large intermediate objects in memory, causing the server to crash with OOM error.

Unbounded Memory Growth in the QUIC PATH_CHALLENGE Handler

Issue summary: Remote peer may exhaust heap memory of the QUIC server or client by flooding it with packets containing PATH_CHALLENGE frames. Impact summary: A malicious remote peer can cause an unbounded memory allocation which can lead to an abnormal termination of the application acting as a QUIC client or server and a Denial of Service. A remote peer may exhaust heap memory by flooding the local QUIC stack with PATH_CHALLENGE frames. The local QUIC stack allocates a PATH_RESPONSE frame for every PATH_CHALLENGE it receives. The allocated PATH_RESPONSE frame gets freed only when the remote peer acknowledges reception of the PATH_RESPONSE frame which will not be done by a malicious peer. The FIPS modules in 4.0, 3.6, 3.5, 3.4, and 3.0 are not affected by this issue. The QUIC stack is outside of OpenSSL FIPS module boundary.

Post-auth memory exhaustion via bitwise match expressions

An authenticated user can cause excess memory usage via bitwise match expression AST processing of $bitsAllSet, $bitsAnySet, $bitsAllClear, and $bitsAnyClear. This contributes to memory pressure and may lead to availability loss by OOM. This issue impacts MongoDB Server v7.0 versions prior to 7.0.34, v8.0 versions prior to 8.0.23, v8.2 versions prior to 8.2.9 and v8.3 versions prior to 8.3.2.

Improperly Controlled Sequential Memory Allocation in Wireshark

Dissection engine LZ77 decompression crash in Wireshark 4.6.0 to 4.6.4 and 4.4.0 to 4.4.14 allows denial of service

Improperly Controlled Sequential Memory Allocation in Wireshark

Dissection engine zlib decompression crash in Wireshark 4.6.0 to 4.6.4 and 4.4.0 to 4.4.14 allows denial of service

Improperly Controlled Sequential Memory Allocation in Wireshark

SMB2 protocol dissector crash in Wireshark 4.6.0 to 4.6.4 and 4.4.0 to 4.4.14 allows denial of service

Improperly Controlled Sequential Memory Allocation in Wireshark

WebSocket protocol dissector crash in Wireshark 4.6.0 to 4.6.4 and 4.4.0 to 4.4.14 allows denial of service

An out-of-memory (OOM) issue in foxinmy/weixin4j

Improperly Controlled Sequential Memory Allocation vulnerability in foxinmy weixin4j (weixin4j-base/src/main/java/com/foxinmy/weixin4j/util modules). This vulnerability is associated with program files CharArrayBuffer.Java, ClassUtil.Java. This issue affects weixin4j.

Improperly Controlled Sequential Memory Allocation in Wireshark

USB HID protocol dissector memory exhaustion in Wireshark 4.6.0 to 4.6.3 and 4.4.0 to 4.4.13 allows denial of service