CVE-2026-63202: 
Java vulnerability analysis and mitigation

CVE-2026-63202 is an unauthenticated CPU-exhaustion denial-of-service vulnerability in the BinaryHttpParser component of the netty-incubator-codec-ohttp library (Maven artifact io.netty.incubator:netty-incubator-codec-bhttp). The flaw causes an infinite loop in the field-section decoding logic, allowing a remote attacker to permanently pin Netty event-loop threads at 100% CPU with a single ~17-byte crafted Binary HTTP message. All versions up to and including 0.0.22.Final are affected; the vulnerability has existed since the parser was introduced. It carries a CVSS v3.1 base score of 7.5 (High) (GitHub Advisory).

The root cause is a control-flow termination defect in BinaryHttpParser.java lines 619–626, classified as CWE-835 (Loop with Unreachable Exit Condition) with a secondary CWE-400 (Uncontrolled Resource Consumption). The loop condition while (fieldSectionLength != 0) instead of > 0 allows the counter to go negative when a field line consumes more bytes than the attacker-declared field-section length, making the exit condition permanently unreachable. Additionally, readFieldLine() can return null and consume zero bytes on a truncated/over-long field line, causing zero-progress iterations that spin indefinitely. Two assert statements (lines 622 and 624) were the only intended guards, but Java assertions are disabled by default in production JVMs, rendering them no-ops. The vulnerability is reachable via the OHTTP codec path: OHttpServerCodec.decode → OHttpRequestResponseContext.parse → ContentDecoder.decodeChunk → BinaryHttpParser.parse, meaning attacker-controlled plaintext (decrypted from a valid HPKE-encapsulated OHTTP request) reaches the vulnerable loop with no intervening application-level guards (GitHub Advisory, Netty Security Advisory).

Successful exploitation results in a complete, persistent denial of service against the OHTTP gateway or client. Each malicious request permanently consumes one Netty event-loop thread at 100% CPU; since Netty event-loop groups have a small fixed thread count (default 2× CPU cores), a handful of concurrent requests exhausts all I/O threads, after which the service accepts no further connections and serves no traffic until the process is restarted. There is no confidentiality or integrity impact — the attack is purely availability-focused and requires no authentication or prior access (GitHub Advisory).

A proof-of-concept has been publicly documented in the advisory, consisting of a 17-byte crafted Binary HTTP message (0001670168016101700101610162016301) that triggers the infinite loop when encapsulated in a valid OHTTP request using the gateway's publicly available HPKE key configuration. The PoC was empirically confirmed to cause a hang with ~100% CPU consumption on one core for the duration of the test. No authentication or special privileges are required. There is no current evidence of in-the-wild exploitation, and the CVE status remains "Reserved" as of the advisory publication date. CISA KEV catalog status and EPSS score are not yet available (GitHub Advisory, Netty Security Advisory).

1. Reconnaissance: Identify OHTTP gateway services built on netty-incubator-codec-ohttp version ≤ 0.0.22.Final. Retrieve the gateway's publicly advertised HPKE key configuration (standard OHTTP behavior per RFC 9458).
2. Craft malicious BHTTP payload: Construct a 17-byte Binary HTTP (RFC 9292) known-length request with a deliberately understated field-section length (e.g., declared length = 0x01) but an actual field line that exceeds that length. Example bytes: 00 01 67 01 68 01 61 01 70 01 01 61 01 62 01 63 01.
3. Encapsulate in OHTTP: Encrypt the malicious BHTTP payload using the gateway's public HPKE key to produce a valid OHTTP request. This step requires no credentials — OHTTP gateways are designed to accept requests from any client with the public key config.
4. Send the request: Transmit the crafted OHTTP request to the gateway's endpoint. HPKE decapsulation succeeds; the attacker-controlled plaintext is passed directly to BinaryHttpParser.parse().
5. Trigger infinite loop: The parser enters readFieldSection(), where the while (fieldSectionLength != 0) loop spins indefinitely — either because fieldSectionLength goes negative (never equals zero) or because readFieldLine() returns null with zero progress. One Netty event-loop thread is pinned at 100% CPU permanently.
6. Scale to full DoS: Repeat with a small number of concurrent requests (equal to or exceeding the event-loop thread count, typically 2× CPU cores) to exhaust all I/O threads and take the gateway fully offline (GitHub Advisory, Netty Security Advisory).

• Network: Sudden spike in OHTTP POST requests from one or more source IPs; requests are small (~17–100 bytes in the BHTTP payload) and syntactically valid at the OHTTP/HPKE layer.
• Process/CPU: One or more JVM threads (Netty event-loop threads, typically named nioEventLoopGroup-*) sustained at 100% CPU with no corresponding increase in throughput or request completion.
• Thread Dump: Stack traces showing threads permanently blocked at io.netty.incubator.codec.bhttp.BinaryHttpParser.readFieldSection(BinaryHttpParser.java:626) → readRequestHead(BinaryHttpParser.java:451) → parse(BinaryHttpParser.java:190).
• Logs: Application logs showing no new requests being processed or connections being accepted after the event-loop threads are exhausted; gateway health checks begin failing.
• JVM Metrics: Thread state for affected threads reported as RUNNABLE (busy spin, not blocked/waiting), with CPU time approximately equal to wall-clock time (GitHub Advisory).

Upgrade the Maven dependency io.netty.incubator:netty-incubator-codec-bhttp (and the parent netty-incubator-codec-ohttp) to version 0.0.23.Final, which contains the fix (Netty Release). The fix changes the loop condition from != 0 to > 0 and promotes the assert-based guards to explicit CorruptedFrameException throws on null/zero-progress returns from readFieldLine(). If immediate upgrade is not possible, consider placing a rate-limiting or connection-limiting reverse proxy in front of the OHTTP gateway to reduce the blast radius, though this does not eliminate the vulnerability. Running the JVM with -ea (assertions enabled) would cause the parser to throw AssertionError instead of spinning, but this is not recommended for production due to performance and stability implications (GitHub Advisory).

The advisory was originally published by maintainer normanmaurer to the netty/netty-incubator-codec-ohttp repository on July 18, 2026, and subsequently published to the GitHub Advisory Database on August 20, 2026. The reporter is credited as "Pig-Tail Reporter." No significant broader media coverage or notable public researcher commentary beyond the advisory itself has been identified at this time (GitHub Advisory).