Netty BinaryHttpParser, CPU-exhaustion DoS via infinite loop, BHTTP-LOOP-001 (High) -DC-Aug2026-1736

Listen to this Post

BinaryHttpParser is the component responsible for decoding Binary HTTP (RFC 9292) messages within the Netty incubator codec for OHTTP (Oblivious HTTP). An OHTTP gateway or client built on this library automatically feeds the decrypted OHTTP body directly into BinaryHttpParser.parse(…) after HPKE decapsulation. The field‑section decoding loop—used to parse the headers after the control data—terminates only when the variable `fieldSectionLength` equals zero. This counter is derived from a wire‑declared length, but the loop subtracts the number of bytes actually consumed by each call to readFieldLine.
Two cooperating defects make the loop infinite. First, the condition is != 0, not > 0. If a field line consumes more bytes than the declared length—which an attacker can easily understate—the counter goes negative and can never hit zero. Second, `readFieldLine` legitimately returns `null` without consuming any bytes when the remaining buffer cannot hold a complete field line (e.g., truncated or over‑long line). In that case the consumed byte count is zero, `fieldSectionLength` remains unchanged, and the loop re‑enters with identical state—a tight busy spin.
The only mechanisms that would catch either scenario are two Java `assert` statements (lines 622 and 624) that check that `lastType != null` and read > 0. However, assertions are disabled by default in all production JVMs; they are stripped unless the `-ea` flag is used. Therefore these guards provide no protection in real‑world deployments.
An attacker only needs to send a single ~17‑byte malicious Binary HTTP message, encrypted under the gateway’s public HPKE key as a perfectly valid OHTTP request. Because HPKE decapsulation succeeds, the plaintext reaches the parser with no application‑level filtering in between. The malformed message sets the declared field‑section length to 1 while the actual field lines are longer, triggering the negative counter and zero‑progress returns. This pins one Netty event‑loop thread at 100% CPU permanently. A handful of such requests exhausts the entire event‑loop group (default size is 2 × cores), after which the gateway or client accepts no new connections and serves no traffic—a complete, persistent denial of service until process restart.
The root cause lies in BinaryHttpParser.java:619–626; the bug has existed since the parser was introduced and is present in the latest code (HEAD d3f2b49, release 0.0.22.Final plus 3 commits). All previously published advisory fixes have been applied, yet this control‑flow flaw remains. The vulnerability is reachable via `io.netty.incubator.codec.ohttp.OHttpRequestResponseContext$ContentDecoderdecodeChunk` (line 214), meaning it is auto‑wired in both server and client codecs. No size limits (e.g., `maxFieldSectionSize` or HttpObjectAggregator) block it because the payload is tiny and the spin is CPU‑bound, not memory‑bound. The issue is distinct from CVE‑2024‑40642, which addressed input validation for method/scheme/authority/path. Empirical testing with assertions off confirms the hang; with assertions on, an `AssertionError` is thrown immediately, proving that the asserts are the only would‑be guard and are absent in production.

DailyCVE Form:

Platform: Netty OHTTP Codec
Version: 0.0.22.Final+ HEAD
Vulnerability: Infinite Loop DoS
Severity: High (7.5)
date: 2026-08-21

Prediction: Patch pending

What Undercode Say:

Malicious BHTTP payload (17 bytes) that triggers the infinite loop
echo -ne '\x00\x01\x67\x01\x68\x01\x61\x01\x70\x01\x01\x61\x01\x62\x01\x63\x01' > malicious.bin
For local testing (if codec sources are available) – feed directly to parser
java -ea -cp ... Poc.java with -ea throws AssertionError
java -cp ... Poc.java without -ea hangs (production behaviour)
Example netcat command if the service accepts raw BHTTP (plaintext for demo)
nc target_host 8080 < malicious.bin
// Java snippet demonstrating the hang (simplified)
ByteBuf in = Unpooled.wrappedBuffer(maliciousBytes);
BinaryHttpParser parser = new BinaryHttpParser();
parser.parse(in, false); // hangs in production

Exploit: (Educational Purposes!)

  1. Obtain the target OHTTP gateway’s public HPKE key configuration (publicly published).
  2. Encrypt the 17‑byte malicious BHTTP payload using the gateway’s key, forming a valid OHTTP request.
  3. Send the encrypted request to the gateway’s OHTTP endpoint.
  4. HPKE decapsulation succeeds; the plaintext is fed to BinaryHttpParser.
  5. The parser enters the infinite spin, consuming one event‑loop thread at 100% CPU.
  6. Repeat with a few more requests to exhaust all threads and bring the service offline.

Protection:

  • Change loop exit condition from `while (fieldSectionLength != 0)` to `while (fieldSectionLength > 0)` so a negative counter terminates.
  • When `readFieldLine` returns `null` or consumes zero bytes while fieldSectionLength > 0, throw a `CorruptedFrameException` instead of re‑looping.
  • Explicitly reject any field line whose consumed bytes would drive `fieldSectionLength` below zero (declared length must be consumed exactly per RFC 9292 §3.6).
  • Remove reliance on assert; promote lines 622 and 624 to unconditional exception throws.
  • Apply the official patch once released (track the Netty incubator repository).

Impact:

  • Unauthenticated, pre‑business‑logic remote denial of service.
  • Each malicious request permanently consumes one Netty I/O thread at 100% CPU.
  • With a small number of requests (≈2×cores), all event‑loop threads are exhausted.
  • Result: complete service outage—no new connections, no traffic processed—persisting until process restart.
  • Availability impact: High; confidentiality and integrity are unaffected.

🎯Let’s Practice Exploiting & Learn Patching For Free:

🎓 Live Courses & Certifications:

Join Undercode Academy for Verified Certifications

🚀 Request a Custom Project:

Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands

Sources:

Reported By: github.com
Extra Source Hub:
Undercode

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow DailyCVE & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin Featured Image

Scroll to Top