CVE-2026-102465 in Vert.x
Summary
by MITRE • 10/15/2026
In Eclipse Vert.x versions [4.0.0, 4.5.34] or [5.0.0,5.0.12] or [5.1.0,5.1.9] or [5.2.0, 5.2.0], the Vert.x Redis client RESP parser pre-allocates arrays to a length declared by the server without enforcing an upper bound. A malicious or compromised Redis server, or an attacker in a man-in-the-middle position, can send a crafted RESP response declaring an extremely large array, push, or attribute length, causing the client to attempt a massive heap allocation. The resulting OutOfMemoryError crashes the Vert.x event loop thread, denying service to all connections and verticles sharing that loop.
The impacted component is io.vertx:vertx-mysql-client.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/15/2026
The vulnerability identified in Eclipse Vert.x affects multiple versions across its 4.x, 5.0.x, 5.1.x, and 5.2.x release lines, specifically impacting the Redis client implementation which utilizes a RESP (Redis Serialization Protocol) parser. The core technical flaw lies in how the client handles array pre-allocation during the parsing of server responses. When receiving data from a Redis server, the Vert.x client attempts to allocate memory for arrays based on the length field declared within the protocol message itself. Crucially, this process lacks any enforcement of an upper bound or sanity check against reasonable limits. This design decision assumes that the remote server is trusted and will not send malformed or maliciously oversized payloads. In a standard deployment where the Redis instance is internal and controlled, this assumption holds true. However, it creates a significant security gap when dealing with untrusted network environments or compromised infrastructure components.
A threat actor who controls or compromises the targeted Redis server, or an attacker positioned in a man-in-the-middle capacity capable of intercepting and modifying traffic between the Vert.x application and the database, can exploit this flaw by sending crafted RESP responses. These malicious packets contain array, push, or attribute length fields set to extremely large values that far exceed normal operational parameters. Upon receiving such a response, the client's parser attempts to pre-allocate memory for an array of that specified size directly on the Java heap. Because there is no validation logic to cap this allocation request, the JVM will attempt to reserve a massive amount of contiguous memory space immediately. This action triggers an OutOfMemoryError exception within the application runtime environment.
The operational impact of this vulnerability is severe and results in a complete denial of service for the affected Vert.x instance. The error occurs on the event loop thread responsible for handling network I/O and processing requests. When the OutOfMemoryError is thrown, it crashes the entire event loop thread rather than being handled gracefully by application code. Since Vert.x relies heavily on these event loops to manage multiple connections and execute various verticles concurrently, crashing one loop often leads to a cascade failure or leaves the application in an unstable state where it can no longer process new requests effectively. This results in immediate service disruption for all users and services depending on that specific instance of the application.
This vulnerability is classified under CWE-789: Memory Allocation with Excessive Size Value, as it involves allocating memory based on a size value derived from untrusted input without proper validation. It also aligns with MITRE ATT&CK technique T1499: Endpoint Denial of Service, specifically through resource exhaustion via application layer attacks. The lack of bounds checking allows an external actor to consume system resources disproportionately relative to the effort required to send the malicious packet. To mitigate this risk, organizations must upgrade their Eclipse Vert.x dependencies to versions that include patches for this issue, ensuring that the RESP parser implements strict limits on array sizes or validates input lengths against configurable maximum thresholds before attempting memory allocation. Additionally, deploying network-level protections such as rate limiting and deep packet inspection can help detect and block anomalous traffic patterns indicative of such exploitation attempts prior to reaching the application layer.