PULSE
FEED
← Todos os CVEs
CVE Watch4 de nov. de 2026

CVE-2026-104895

The asynchronous Smile parser (NonBlockingByteArrayParser) uses a raw-binary length prefix taken from untrusted input to allocate a byte[] b

CVSS

7.5

Alta

EPSS

0.4%

p32

KEV

—

Exploit Today

10

0-100

Publicado: 28 de out. de 2026 · Última mod.: 4 de nov. de 2026 · CWE-789

EPSS · 30d
0.4%EPSS · 30 dias0.4%
2026-10-282026-11-07
Descrição técnica

The asynchronous Smile parser (NonBlockingByteArrayParser) uses a raw-binary length prefix taken from untrusted input to allocate a byte[] before the body is read, with no upper bound and no overflow check. On the raw-binary marker 0xFD, _decodeVInt() computes (value << 6) + (i & 0x3F) without the (value >>> 25) != 0 overflow guard present in the blocking SmileParser._readUnsignedVInt, and _startRawBinary then allocates the declared length immediately. A Smile feed of roughly ten bytes can therefore force an eager allocation of approximately 2 GB, producing an OutOfMemoryError on reactive or asynchronous Smile endpoints. A VInt crafted to overflow int yields a negative length and a NegativeArraySizeException, a RuntimeException that is not a JacksonException and so escapes the parser contract. Either outcome crashes the request or processing thread. This is the same class of issue as CVE-2020-28491 in the CBOR parser of this library, which was fixed with a LONGEST_NON_CHUNKED_BINARY guard; the asynchronous Smile parser never received the equivalent guard. No privileges or user interaction beyond the ability to submit data for parsing are required.

Referências oficiais
CVEs relacionados
CVECVSSEPSSKEVRExploitTítuloMod.
CVE-2026-1236167.5 ALT
—
———imgproxy from 3.3.0 before 4.0.16 contains an unbounded memory allocation vulnerability in the ICO loader that fails to validate the data_size field. Attackers can supply a crafted 23-byte ICO file declaring a ~4GB data_size to trigger memory exhaustion and worker crashes without authentication.11h
CVE-2026-1235637.5 ALT
—
———Devalue before 5.9.3 contains a validation bypass vulnerability that allows custom ArrayBuffer revivers to skip typed-array allocation checks in the parse function. Attackers can supply very small crafted input processed by a malformed ArrayBuffer reviver to allocate massive ArrayBuffers, causing memory exhaustion and denial of service.11h
CVE-2026-1167877.5 ALT
41.6%
——12FreeSWITCH is a Software Defined Telecom Stack enabling the digital transformation from proprietary telecom switches to a software implementation that runs on any commodity hardware. Prior to 1.11.2, mod_event_socket used an unauthenticated Content-Length value directly as the allocation size for an Event Socket message body. Negative or extremely large values could overflow the terminator calculation or force an allocation failure through a helper that aborts the FreeSWITCH process. The header is parsed before the Event Socket password, so any host admitted by apply-inbound-acl can trigger termination with its first packet; the default loopback ACL limits ordinary installations to local clients. The outbound socket dialplan path is also affected when FreeSWITCH connects to a hostile application server, and process termination drops every active call until the service is restarted. This issue is fixed in version 1.11.2.3d
CVE-2026-1220524.3 MÉD
26.3%
——8A vulnerability has been found in laspy up to 2.7.0. Affected by this issue is some unknown functionality of the file laspy/lasreader.py of the component LAS File Handler. The manipulation leads to uncontrolled memory allocation. Remote exploitation of the attack is possible.3d
CVE-2026-1221295.3 MÉD
34.6%
——10CESNET ipfixcol2 2.7.1 before 2.9.0 contains a memory allocation vulnerability in Lz4Decoder::read_start_header() that allows unauthenticated attackers to exhaust memory by declaring unbounded ring buffer sizes. Attackers can open TCP connections sending LZ4 start headers with very large buffer sizes, forcing up to 4 GiB allocations per connection and denying collector service.3d
CVE-2026-103582—
12.0%
——4Unbounded memory allocation and missing frame size validation in Apache NMS ActiveMQ (the .NET OpenWire client, package Apache.NMS.ActiveMQ) before 2.3.0. The OpenWire unmarshalling code trusted the frame size and the length and count fields read from the network. It did not enforce a maximum frame size, and it did not check that decoded lengths fit within the frame being read. A malicious or compromised broker, or an attacker able to intercept and modify an unencrypted connection, could send a crafted OpenWire frame with an oversized or negative length. This could cause the client to attempt very large memory allocations, leading to excessive memory consumption, an OutOfMemoryException or an uncaught exception, and a denial of service of the client application. Users are recommended to upgrade to version 2.3.0, which enforces a configurable maximum frame size and validates lengths against the size of the frame being read.4d