CVE-2026-63124: 
Java vulnerability analysis and mitigation

CVE-2026-63124 is a denial-of-service vulnerability in the io.netty.incubator:netty-incubator-codec-bhttp Maven package (part of the netty-incubator-codec-ohttp project) caused by an infinite loop in the Binary HTTP parser. When a known-length Binary HTTP field section ends exactly after a complete field line, the BinaryHttpParser / BinaryHttpDecoder enters a non-terminating parse loop, allowing a remote unauthenticated peer to hang the parsing thread indefinitely. All versions up to and including 0.0.22.Final are affected; the issue was fixed in 0.0.23.Final. The advisory was originally published on July 12, 2026, and added to the GitHub Advisory Database on August 20, 2026. It carries a CVSS v3.1 base score of 7.5 (High) (Github Advisory, Netty Security Advisory).

The root cause is classified as CWE-400 (Uncontrolled Resource Consumption) and CWE-835 (Loop with Unreachable Exit Condition). In BinaryHttpParser.java, the method readFieldSection(...) enters a while (fieldSectionLength != 0) loop (line 619) and calls readFieldLine(...) on each iteration, subtracting the number of bytes consumed from fieldSectionLength. However, readFieldLine(...) returns null without consuming any bytes when a field line ends exactly at the boundary of the readable buffer slice (lines 678–681), because it checks if (sumBytes >= in.readableBytes()) return null. With JVM assertions disabled (the production default), the assert read > 0 guard at line 622 is inactive, so fieldSectionLength is decremented by zero on every iteration and the loop never terminates. The boundary condition is triggered by a structurally valid known-length field section containing exactly one complete field line with no trailing byte — for example, a field section of length 4 with a single field a: b. A public proof-of-concept demonstrating the hang is included in the advisory (Github Advisory, Netty Security Advisory).

Successful exploitation pins the Netty event-loop thread or worker responsible for the affected channel indefinitely, degrading or eliminating availability for all other channels sharing the same event loop. Because the same BinaryHttpParser is invoked inside the OHTTP stack after decryption of protected payloads, authenticated OHTTP peers with valid decryption keys can also trigger the condition in the inner BHTTP parser. There is no confidentiality or integrity impact; the vulnerability is purely an availability (DoS) issue (Github Advisory, Netty Security Advisory).

No authentication or privileges are required, and no user interaction is needed — any remote peer capable of delivering crafted BHTTP bytes to a vulnerable Netty pipeline can trigger the infinite loop. A working proof-of-concept is publicly documented in the GitHub Security Advisory. There is no current evidence of in-the-wild exploitation, no known threat actor attribution, and the CVE status remains "Reserved" as of the advisory publication date. CISA KEV catalog inclusion and EPSS score data are not yet available (Github Advisory, Netty Security Advisory).

1. Identify target: Locate a service that uses io.netty.incubator:netty-incubator-codec-bhttp version ≤ 0.0.22.Final in its Netty pipeline (e.g., an OHTTP relay or gateway accepting Binary HTTP input).
2. Craft malformed BHTTP request: Construct a known-length Binary HTTP request where the field section length exactly matches the byte length of one complete field line with no trailing byte. Example: field section length = 4, field name = a (1 byte), field value = b (1 byte), plus two varint length bytes.
3. Send the payload: Transmit the crafted BHTTP bytes to the target's network endpoint. No authentication or special headers are required.
4. Trigger infinite loop: The BinaryHttpParser.readFieldSection(...) method enters the while (fieldSectionLength != 0) loop; readFieldLine(...) returns null without consuming bytes; with JVM assertions disabled, fieldSectionLength is decremented by zero indefinitely.
5. Achieve DoS: The Netty event-loop thread handling the channel is pinned, blocking processing for all other channels on the same event loop and causing service degradation or complete unavailability (Github Advisory, Netty Security Advisory).

• Process: Netty JVM process showing sustained 100% CPU usage on a single thread with no corresponding increase in throughput or request completion.
• Logs: Absence of request completion log entries for channels that received Binary HTTP input; Netty pipeline stall or timeout warnings from other channels sharing the same event loop.
• Network: Incoming Binary HTTP connections that remain open indefinitely without producing a response; small, structurally minimal BHTTP payloads (e.g., < 20 bytes) arriving from external peers.
• Application Metrics: Event-loop utilization metrics spiking to 100% while active connection count remains low; health-check endpoints becoming unresponsive due to event-loop starvation (Github Advisory).

Upgrade io.netty.incubator:netty-incubator-codec-bhttp to version 0.0.23.Final, which is the patched release that resolves the infinite loop (Netty Release). If an immediate upgrade is not possible, consider enabling JVM assertions (-ea) as a temporary diagnostic measure — this will cause the parser to throw an AssertionError instead of looping, though this is not a production-safe workaround. Additionally, deploying network-level controls (e.g., rate limiting, connection timeouts, or a reverse proxy that enforces maximum request processing time) can reduce the blast radius of exploitation until the patch is applied (Github Advisory, Netty Security Advisory).

The vulnerability was discovered and reported by Thai Son Dinh (sondt99 / VuiVeIshere) from VinSOC Labs (R&D) and published by Netty maintainer normanmaurer on July 12, 2026. No significant broader media coverage or notable public researcher commentary beyond the official advisory has been identified at this time (Netty Security Advisory).