An unauthenticated attacker can supply a malformed BHTTP request where the declared field-section length does not match the actual data. If the parser consumes zero bytes or consumes more bytes than declared, the loop enters an infinite busy-spin. Because the code relies on Java assert statements - which are stripped in production JVM environments - to guarantee termination and progress, the defect is fully exposed to remote exploitation. A small number of these requests can pin every available Netty event-loop thread at 100% CPU, resulting in a complete denial of service for OHTTP gateways or clients until the process is restarted.

Attack Chain

1. Attacker obtains the target OHTTP gateway's public HPKE key configuration.
2. Attacker crafts a malicious BHTTP message where the declared field-section length is understated relative to the actual field line contents.
3. Attacker wraps the malicious BHTTP payload within a standard OHTTP request, encrypted with the gateway's public key.
4. OHTTP gateway receives the request and decrypts the chunk into the binaryHttpCumulation buffer.
5. OHttpRequestResponseContext passes the attacker-controlled plaintext directly to BinaryHttpParser.parse.
6. BinaryHttpParser enters the readFieldSection method and triggers the vulnerable while loop (lines 619-626).
7. The loop fails to terminate due to the != 0 condition or zero-byte progress, initiating an infinite CPU-bound spin.
8. Repeating the request exhausts the Netty event-loop group, leading to a total denial of service.

Impact

The attack results in an unauthenticated, persistent denial of service. By pinning the event-loop threads of an OHTTP gateway or client, the attacker renders the service incapable of accepting new connections or processing traffic. The impact is significant for high-availability infrastructure relying on Netty-based OHTTP gateways, as the service remains unavailable until manual intervention (process restart) occurs.

Recommendation

• Update netty-incubator-codec-bhttp to a version containing the patched BinaryHttpParser logic that replaces the vulnerable while loop with explicit exception handling.
• Promote input validation invariants previously handled by assert (lines 622, 624) to explicit CorruptedFrameException checks to ensure security regardless of JVM assertion settings.
• Verify that production deployments are not bypassing framing errors; ensure the parser enforces strict adherence to RFC 9292 regarding declared versus actual field-section length consumption.