Impact

Successful exploitation results in an application-level denial-of-service. By repeatedly triggering the memory leak, an attacker can exhaust the target system's native memory, causing the JVM process to crash or become unresponsive to legitimate OHTTP traffic. This vulnerability is particularly critical for high-traffic OHTTP gateways exposed to the internet.

Recommendation

• Upgrade the 'netty-incubator-codec-ohttp' dependency to version 0.0.23.Final or higher immediately.
• Audit existing deployments for high memory utilization or 'OutOfMemoryError: Direct buffer memory' exceptions correlated with AEAD decryption errors.
• Implement rate limiting on OHTTP gateway endpoints to mitigate the frequency at which an attacker can trigger the vulnerable decryption path.

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.