Easily map the attack path and prioritize which CVEs are a threat to your organization
Miggo AIGenerate vendor-ready rules for the observed attack patterns, plus reasoning and safe deployment guidance
Miggo AIRoot Cause AnalysisThe vulnerability is a Denial of Service (DoS) caused by an infinite loop in the BinaryHttpParser component of netty-incubator-codec-ohttp. The root cause lies in the readFieldSection method, which is responsible for parsing the field section of a Binary HTTP message. The analysis of the fixing commit 89d6cfc67e034a92e6eef9ccb9829b6e358a91ea confirms the flaw. The vulnerable version of the code used a while (fieldSectionLength != 0) loop condition. An attacker could craft a malicious message where the actual length of a field line is greater than the declared fieldSectionLength. This would cause fieldSectionLength to become negative, but not zero, making the loop condition != 0 always true. Furthermore, if a field line was truncated, the internal readFieldLine method could return without consuming any bytes, leading to a tight busy-spin loop, consuming 100% of a CPU core.
The patch addresses this by adding two crucial checks inside the loop. First, it throws a CorruptedFrameException if readFieldLine makes zero progress (read <= 0). Second, it throws an exception if the number of bytes read (read) is greater than the remaining fieldSectionLength, preventing the counter from becoming negative. The vulnerable functions identified are readFieldSection (containing the flawed logic) and the functions in its call stack (readRequestHead, parse, and decodeChunk) which would appear in a profiler during exploitation, as confirmed by the stack trace in the vulnerability report.
io.netty.incubator.codec.bhttp.BinaryHttpParser.readFieldSectioncodec-bhttp/src/main/java/io/netty/incubator/codec/bhttp/BinaryHttpParser.java
io.netty.incubator.codec.bhttp.BinaryHttpParser.readRequestHeadcodec-bhttp/src/main/java/io/netty/incubator/codec/bhttp/BinaryHttpParser.java
io.netty.incubator.codec.bhttp.BinaryHttpParser.parsecodec-bhttp/src/main/java/io/netty/incubator/codec/bhttp/BinaryHttpParser.java
io.netty.incubator.codec.ohttp.OHttpRequestResponseContext$ContentDecoder.decodeChunkcodec-ohttp/src/main/java/io/netty/incubator/codec/ohttp/OHttpRequestResponseContext.java
| Package Name | Ecosystem | Vulnerable Versions | First Patched Version |
|---|---|---|---|
| io.netty.incubator:netty-incubator-codec-bhttp | maven | <= 0.0.22.Final | 0.0.23.Final |
assertA single ~17-byte Binary HTTP message — encapsulated by an unauthenticated attacker inside a normal OHTTP request, using the gateway's public key configuration — pins one Netty event-loop thread at 100% CPU permanently. A handful of such requests exhausts the entire event-loop group and takes the OHTTP gateway (or client) fully offline.
BinaryHttpParser.java:619-626:
HeaderType lastType = HeaderType.PSEUDO_HEADER;
while (fieldSectionLength != 0) { // 619 — "!= 0", not "> 0"
int readableBytes = in.readableBytes();
lastType = readFieldLine(in, headers, lastType, trailers);
assert lastType != null; // 622 — no-op without -ea
int read = readableBytes - in.readableBytes();
assert read > 0; // 624 — no-op without -ea
fieldSectionLength -= read; // 625
}
Two cooperating defects:
Counter can never hit zero. fieldSectionLength is the declared field-section byte length read from the wire (line 592). The loop subtracts the bytes each readFieldLine actually consumes. If a field line consumes more bytes than the (attacker-understated) declared length, fieldSectionLength goes negative and != 0 stays true forever.
Zero-progress iterations. readFieldLine (lines 654-707) returns null without consuming any bytes when the remaining buffer cannot hold a complete field line — at lines 656, 664, 670, and 681 (the in.skipBytes(sumBytes) that advances the reader is only reached on the success path, line 705). When it returns null, read == 0, fieldSectionLength is unchanged, and the loop re-enters with identical state — a tight busy spin.
The only constructs that would have stopped either case are the assert statements on lines 622 and 624, which the JVM strips unless started with -ea. Production deployments do not run with assertions enabled.
Attacker model: OHTTP gateways publish their HPKE key configuration so that any client can encrypt requests to them. The attacker therefore encrypts a malicious BHTTP body under the gateway's public key — a perfectly valid OHTTP request. HPKE decapsulation succeeds; the plaintext is attacker-chosen.
OHttpServerCodec.decode → OHttpRequestResponseContext.parse → chunk decode → ContentDecoder.decodeChunk.OHttpRequestResponseContext.java:211 decrypts the chunk into decryptedChunk; line 212 cumulates it; line 214 calls binaryHttpParser.parse(binaryHttpCumulation, completeBodyReceived) — attacker-controlled plaintext, no application code in between.parse → READ_KNOWN_LENGTH_REQUEST_HEAD → readRequestHead (line 190).readRequestHead reads the control data, then at lines 445-451 slices all remaining readable bytes as the field section and calls readFieldSection(..., knownLength=true, maxFieldSectionSize).readFieldSection:
checkFieldSectionTooLarge(fieldSectionLength, max) (line 607): bounds only the declared length, which the PoC sets to 1. Passes — not a barrier.in.readableBytes() < sumBytes (line 609): sumBytes is built from the declared length, also tiny. Passes — not a barrier.assert (lines 622, 624): no-ops in production. Defeated by default.No reachable guard bounds the actual consumption or forces progress. maxFieldSectionSize is irrelevant because the declared length is small and the loop is CPU-bound on a fixed, small buffer (no allocation, no memory growth to trip any size cap).
The real codec-bhttp sources were compiled unmodified against netty 4.1.135.Final (the version pinned in pom.xml). The harness builds a valid known-length BHTTP request whose declared field-section length (0x01) is understated relative to the actual field line, then calls parse(in, true) on a worker thread with a 6-second watchdog. No payload, no side effects — purely a timing/CPU oracle.
Malicious message (17 bytes):
00 01 67 01 68 01 61 01 70 01 01 61 01 62 01 63 01
│ └method g └scheme h └auth a └path p │ └hdr a:b──┘ └ partial line
└ framing 0 (known-length request) └ declared field-section length = 1
Observed (production default, assertions OFF):
[*] malicious BHTTP bytes (17): 0001670168016101700101610162016301
[!!] HANG CONFIRMED: parse() still running after 6000 ms
[!!] worker thread CPU time: 6029 ms (≈100% of one core => busy spin)
[!!] worker stack (top frames):
at io.netty.incubator.codec.bhttp.BinaryHttpParser.readFieldSection(BinaryHttpParser.java:626)
at io.netty.incubator.codec.bhttp.BinaryHttpParser.readRequestHead(BinaryHttpParser.java:451)
at io.netty.incubator.codec.bhttp.BinaryHttpParser.parse(BinaryHttpParser.java:190)
CPU time ≈ wall time ⇒ a busy spin (RUNNABLE), not a blocked wait.
Controls:
-ea: parse() throws AssertionError at readFieldSection:624 immediately — proving the assertion is the only would-be guard and is absent in production.parse() returns DefaultBinaryHttpRequest promptly — proving the harness does not hang on valid input.PoC sources: findings/netty-incubator-codec-ohttp/raw/Poc.java (hang + control 1) and raw/Poc2.java (negative control).
Unauthenticated, pre-business-logic remote denial of service. Each malicious request permanently consumes one Netty event-loop thread at 100% CPU. Netty event-loop groups have a small fixed thread count (default 2 × cores); a handful of requests exhausts every I/O thread, after which the gateway/client accepts no further connections and serves no traffic — a complete, persistent DoS that survives until process restart. Availability impact High; no confidentiality/integrity impact.
maxFieldSectionSize caps it." No — the declared length in the PoC is 1; the cap (line 607) checks the declared value only. The spin happens on a 17-byte buffer with no allocation. Refutation fails.HttpObjectAggregator blocks it." No — the bug is CPU-bound, not memory-bound. The whole malicious message is tiny and well within any size limit. Refutation fails.ALLOWED_TOKEN/ALLOWED_SCHEME validators, lines 76-122/461-466) is present and unrelated. This is a control-flow/termination defect in field-section length accounting. Distinct class, distinct code.readFieldSection:626; CPU≈wall confirms a spin; the -ea control throws at the exact assert; the well-formed control returns. The hang is for the claimed reason.completeBodyReceived must be true." Not required — the loop is inside readFieldSection, reached via readRequestHead once the control data is present, independent of that flag. The flag only affects a branch taken after readRequestHead returns null, which never happens here.No concrete blocker survived. Verdict: CONFIRMED.
while (fieldSectionLength > 0) so an overshoot (negative counter) terminates.null / zero-progress return from readFieldLine while fieldSectionLength > 0 as a hard framing error — throw CorruptedFrameException("truncated or over-long field line") instead of re-looping.fieldSectionLength below 0 (the declared length must be consumed exactly, per RFC 9292 §3.6).assert for wire-format invariants on attacker-controlled input; assertions are disabled in production. Promote lines 622/624 to explicit exceptions.Example:
while (fieldSectionLength > 0) {
int readableBytes = in.readableBytes();
lastType = readFieldLine(in, headers, lastType, trailers);
int read = readableBytes - in.readableBytes();
if (lastType == null || read <= 0) {
throw new CorruptedFrameException("truncated or over-long field line");
}
if (read > fieldSectionLength) {
throw new CorruptedFrameException("field line exceeds declared field-section length");
}
fieldSectionLength -= read;
}
!= 0 / zero-progress structure; the fix above should cover both. A dedicated trace of getIndeterminateLength (lines 538-566) under non-default maxFieldSectionSize is recorded separately as a lead.maxFieldSectionSize for the OHTTP codecs is 8 * 1024 (OHttpCodecBuilder.DEFAULT_MAX_FIELD_SECTION_SIZE), and is irrelevant to this CPU-bound spin.