CVE-2026-118488 in Vert.x
Summary
by MITRE • 11/03/2026
In Eclipse Vert.x versions [4.0.0, 4.5.35] or [5.0.0, 5.2.2], when a malicious server keeps sending bytes on an EOL-terminated line (not length-prefixed, for example a simple string [1]), we'll keep growing the buffer without bounds, eventually leading to an OOM. We need to have a configurable limit for EOL-terminated lines.
If a malicious server sends a specially crafted RESP response (for example a bulk string [2] with missing CRLF trailer), the parser enters an infinite loop where it keeps parsing the same buffer and pushing the same response to the caller, which may lead e.g. to an OOM if the consumer just buffers the responses. We must fix the parser to avoid this infinite looping.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 11/03/2026
The vulnerability described affects Eclipse Vert.x versions ranging from 4.0.0 through 4.5.35 and 5.0.0 through 5.2.2, presenting two distinct but related denial-of-service vectors rooted in improper input validation and state management within the networking layer. The first vector involves EOL-terminated line parsing where a malicious server continuously transmits bytes without adhering to expected length-prefixed protocols or proper termination sequences that would normally bound buffer growth. In this scenario, the application maintains an internal buffer for accumulating data until a delimiter is detected. Because there is no configurable maximum limit on the size of these EOL-terminated lines, the buffer expands indefinitely as more bytes are received from the untrusted source. This unchecked memory allocation eventually exhausts available heap space, triggering an OutOfMemoryError that crashes the application or degrades system stability significantly.
The second vector targets the RESP protocol parser used for communicating with Redis and similar services. When a malicious server sends a specially crafted response, such as a bulk string missing its expected CRLF trailer sequence, the parser fails to detect this malformed state correctly. Instead of raising an error or resetting the connection state, the parser enters an infinite loop. It repeatedly processes the same buffer content and pushes identical responses to the calling application logic. If the consumer of these responses attempts to store them in memory rather than processing them immediately and discarding duplicates, this rapid accumulation leads to a similar OutOfMemoryError condition. This behavior represents a resource exhaustion attack where minimal network traffic from an attacker can cause disproportionate CPU and memory consumption on the victim server due to the tight loop execution.
From a technical classification perspective, these issues align with CWE-400 Uncontrolled Resource Consumption and CWE-787 Out-of-bounds Write if the buffer expansion leads to heap corruption in lower-level implementations, though primarily they manifest as resource exhaustion vulnerabilities. In terms of MITRE ATT&CK mapping, this corresponds to T1496 Resource Hijacking, specifically sub-component loop consumption or memory allocation abuse, where an attacker leverages inefficient parsing logic to consume system resources and disrupt service availability. The root cause lies in the absence of strict boundary checks on input data size and insufficient state machine validation for protocol compliance during stream processing.
To mitigate these vulnerabilities, it is imperative to implement configurable limits for EOL-terminated line lengths within the Vert.x configuration settings. Administrators should set a maximum allowable buffer size that triggers an exception or connection closure when exceeded, preventing unbounded memory growth. For the RESP parser issue, the code must be updated to strictly validate protocol conformance, ensuring that malformed responses such as those missing trailing CRLF sequences are rejected immediately rather than processed in a loop. Implementing timeouts for incomplete reads and adding explicit checks for infinite parsing loops will further harden the application against these denial-of-service attacks. Upgrading to patched versions of Eclipse Vert.x is essential, as newer releases include fixes that enforce these limits and correct the parser logic to handle malformed inputs gracefully without entering non-terminating states.