high · 7.5CVE-2026-63202Aug 20, 2026

CVE-2026-63202: netty-incubator-codec-bhttp BinaryHttpParser Infinite Loop DoS

Shubham Kandhare
Security Engagement Manager, SecureLayer7

A 17-byte malformed Binary HTTP message sent inside a normal OHTTP request can permanently pin a Netty event-loop thread at 100% CPU, taking the gateway offline with no authentication required.

Packageio.netty.incubator:netty-incubator-codec-bhttp
Ecosystemmaven
Affected<= 0.0.22.Final
Fixed in0.0.23.Final
CVE-2026-63202: netty-incubator-codec-bhttp BinaryHttpParser Infinite Loop DoS

The problem

BinaryHttpParser.readFieldSection uses != 0 instead of > 0 as its loop exit condition. An attacker who understates the declared field-section length in the wire message causes the counter to go negative, making the exit condition permanently true.

A second defect compounds this: readFieldLine returns null without consuming any bytes when the buffer holds a truncated field line. When that happens the counter does not change, and the loop re-enters with identical state, creating a tight busy spin. Both assert guards that should catch this are no-ops in any production JVM (assertions disabled by default), so there is no runtime protection.

Proof of concept

A working proof-of-concept for CVE-2026-63202 in io.netty.incubator:netty-incubator-codec-bhttp, with the exact payload below.

bash
# Malicious 17-byte known-length BHTTP request (hex)
# Framing 0x00 = known-length request
# Control data: method "g" (0x67), scheme "h" (0x68), authority "a" (0x61), path "p" (0x70)
# Declared field-section length = 0x01 (1 byte), actual field line consumes more
# --> fieldSectionLength goes negative; loop never exits
00 01 67 01 68 01 61 01 70 01 01 61 01 62 01 63 01

# Java harness (stripped to essential call)
byte[] malicious = hexToBytes("0001670168016101700101610162016301");
ByteBuf in = Unpooled.wrappedBuffer(malicious);
new BinaryHttpParser(8192).parse(in, true);
// Thread pins at BinaryHttpParser.readFieldSection:626 indefinitely (no -ea flag)

The root cause is a termination defect in BinaryHttpParser.java lines 619-626. The loop condition while (fieldSectionLength != 0) allows a negative value to satisfy it forever, because an attacker-controlled declared length smaller than the actual bytes consumed drives the counter below zero.

The cooperating defect is that readFieldLine (lines 654-707) takes the early-return null path without calling skipBytes when the buffer cannot satisfy a complete field line, so read == 0 and the counter is never modified, producing a zero-progress spin. The patch fixes both by changing the condition to while (fieldSectionLength > 0) and promoting the two assert statements on lines 622 and 624 to hard CorruptedFrameException throws, so a null return or zero-read is an immediate parse error rather than a re-entry.

CWE-835 (Loop with Unreachable Exit Condition) is the primary class; CWE-400 (Uncontrolled Resource Consumption) is the consequence.

The fix

Upgrade to io.netty.incubator:netty-incubator-codec-bhttp:0.0.23.Final (and the matching codec-ohttp artifact). The patch changes the loop guard from != 0 to > 0 and replaces the no-op assert statements with explicit CorruptedFrameException throws on null return or zero-byte-progress from readFieldLine.

No workaround exists at the application layer because the spin is CPU-bound on a tiny, size-compliant buffer that passes all upstream size checks.

Reporter not attributed.

References: [1][2][3]

Related research