Eclipse Vert.x STOMP CVE-2026-118487

The application must use the vertx-stomp module and run either a Vert.x STOMP server or STOMP client reachable by an untrusted peer. For the server case, no authentication or special configuration is required - the description explicitly states a malicious client can exploit it before or after authentication against default parsing behaviour (FrameParser builds its RecordParser with no maxRecordSize). For the client case, the victim client must connect to an attacker-controlled STOMP server. The only real limiting factor is that the vulnerable vertx-stomp module must be deployed and exposed to a peer the attacker controls; affected versions are [4.0.0, 4.5.35] and [5.0.0, 5.2.2]. There is no complete mitigation other than upgrading: fixed in 4.5.36 (4.x branch) and 5.2.3 (5.x branch).

All impact signals point to availability only: the CVSS 3.1 vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H scores 7.5 (High) driven entirely by A:H, with no confidentiality or integrity loss. The network vector, low attack complexity, and PR:N mean a remote unauthenticated peer can trigger it - and the description confirms a malicious client can hit a server before or after authentication, while a malicious server can hit a connecting client. No EPSS score was supplied, this CVE is not listed in CISA KEV, and no public exploit was identified, so there is no evidence of active exploitation; the trigger (streaming bytes without a newline so RecordParser accumulates unbounded) is simple and well described, which keeps the barrier to building an exploit low even though none is published. The vuln.today priority is this_week, consistent with a serious but non-emergency DoS: real priority for anyone running the vertx-stomp module exposed to untrusted peers, but lower urgency than a code-execution or data-exposure flaw. Key missing data: no EPSS, no SSVC decision-framework breakdown, and no KEV/POC signals to corroborate exploitation likelihood - prioritization rests on the CVSS vector, the clear mechanism, and the this_week label.

An attacker opens a STOMP connection to a Vert.x STOMP server (no authentication required) and streams bytes continuously without ever sending a newline, forcing the FrameParser's RecordParser to buffer the stream indefinitely until the JVM heap is exhausted and the process crashes. The same works in reverse: a malicious STOMP server can crash a connecting Vert.x STOMP client. No public exploit code was identified, but the technique requires only a raw socket and a byte stream.