CVE-2026-118487 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], the `FrameParser` in vertx-stomp creates a `RecordParser` without setting `maxRecordSize`, so any peer that streams bytes continuously without a newline character causes the parser to accumulate data indefinitely. Both the STOMP server and the STOMP client are affected: a malicious server can exploit this against a connecting client, and a malicious client can exploit this against a server before or after authentication. Sustained byte streaming exhausts JVM heap memory, crashing the affected process and causing a complete denial of service.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 11/03/2026
The vulnerability identified in Eclipse Vert.x versions ranging from 4.0.0 to 4.5.35 and 5.0.0 to 5.2.2 represents a critical resource exhaustion flaw within the STOMP protocol implementation, specifically located in the FrameParser component of the vertx-stomp module. This issue stems from an improper configuration of the underlying RecordParser instance used for parsing incoming network frames. When initializing this parser, developers failed to set the maxRecordSize parameter, which serves as a safeguard against unbounded memory allocation during data ingestion. In standard protocol implementations, such parsers are designed to buffer input until a specific delimiter or frame boundary is detected, at which point the accumulated data is processed and the buffer is cleared. However, without an explicit maximum size constraint, the parser operates with no upper limit on how much data it will accumulate in memory before processing occurs.
The technical mechanism of this flaw relies on the behavior of continuous byte streams that lack the expected newline characters or frame delimiters defined by the STOMP protocol specification. A malicious actor can exploit this by establishing a connection and transmitting a high-volume stream of bytes without including any terminating newlines. Because the parser is configured to wait for these delimiters before finalizing the record, it continues to append incoming data to an internal buffer indefinitely. This behavior transforms what should be a bounded memory operation into an unbounded one, directly tying the application's memory consumption to the volume and speed of the attacker's input stream rather than any predefined protocol limits or system constraints.
The operational impact of this vulnerability is severe, resulting in a complete denial of service through JVM heap exhaustion. As the malicious byte stream continues, the Java Virtual Machine allocates more and more heap space to store the accumulating data within the RecordParser buffer. Eventually, the application runs out of available memory, triggering an OutOfMemoryError that typically causes the process to crash or become unresponsive. This affects both sides of a STOMP connection; a malicious server can exploit this against a connecting client by sending malformed frames, and conversely, a malicious client can target the server with similar attacks before authentication is completed or even after successful login. The lack of distinction between pre-authentication and post-authentication attack vectors means that the vulnerability poses a significant risk to any service relying on Vert.x for STOMP communication, regardless of whether access controls are in place.
From a classification perspective, this flaw aligns with CWE-400, which describes uncontrolled resource consumption, specifically manifesting as memory exhaustion. It also maps closely to ATT&CK technique T1496, Resource Hijacking, where an adversary consumes resources to degrade service availability for legitimate users. The absence of input validation and size limits is a common pattern in network-facing components that handle variable-length data structures, highlighting the importance of enforcing strict boundaries on all external inputs regardless of their source or trust level.
To mitigate this vulnerability, organizations must upgrade Eclipse Vert.x to versions 4.5.36 or later for the 4.x branch and 5.2.3 or later for the 5.x branch, where the FrameParser has been patched to enforce appropriate limits on record size. For environments that cannot immediately patch due to dependency constraints, implementing a reverse proxy or gateway with strict payload size limitations can provide an additional layer of defense by dropping oversized frames before they reach the vulnerable application server. Additionally, developers should review any custom STOMP implementations within their codebase to ensure that RecordParser instances are always initialized with explicit maxRecordSize values set to reasonable limits based on expected protocol frame sizes, thereby preventing similar unbounded memory growth in other parts of the system.