Netty OHTTP EUVD-2026-34308

Exploitation requires two concurrent conditions: the target must be running netty-incubator-codec-ohttp prior to 0.0.22.Final, and the hosting JVM must be configured so that sun.misc.Unsafe is unavailable to Netty - specifically via the -Dio.netty.noUnsafe=true system property, a SecurityManager policy restricting Unsafe access, or use of a non-HotSpot JVM (e.g., GraalVM native image, IBM J9 in certain configurations). Without one of these JVM constraints, PooledDirectByteBuf.hasMemoryAddress() returns true and the vulnerable fallback path is never invoked. The CVSS PR:N vector confirms no authentication is required - any network-reachable attacker able to send HTTP requests to the OHTTP endpoint can trigger the bug. User interaction is not required (UI:N). The primary limiting factor is the non-default JVM configuration: while not common in standard production HotSpot deployments, it may appear in hardened environments, containerized workloads applying strict Unsafe restrictions, or environments running on alternative JVMs.

The CVSS 4.0 score of 6.8 (Medium) with vector AV:N/AC:L/AT:N/PR:N/UI:N reflects network-reachable, low-complexity exploitation with no authentication required, yielding VC:H and VA:H on the vulnerable system. However, the AT:N (No Attack Requirements) designation is in direct tension with the description's explicit prerequisite of a non-default JVM configuration: the vulnerable fallback path is only reached when the JVM is started with -Dio.netty.noUnsafe=true, when a SecurityManager restricts Unsafe access, or when running on a non-HotSpot JVM. On standard HotSpot deployments without these restrictions, hasMemoryAddress() returns true and the buggy fallback is never invoked, rendering the vulnerability unexploitable. This configuration dependency meaningfully narrows the real-world attack surface below what the raw CVSS vector implies. No EPSS score was included in the provided intelligence. The E:U CVSS modifier (Unexploited), the absence of a CISA KEV listing, and no public POC all confirm there is no evidence of active exploitation or weaponized code at time of analysis. Organizations running OHTTP gateways under Unsafe-restricted JVM configurations should treat this as high priority; standard HotSpot deployments without such restrictions face substantially lower practical risk.

An attacker identifies an Oblivious HTTP gateway running netty-incubator-codec-ohttp prior to 0.0.22.Final on a JVM started with -Dio.netty.noUnsafe=true or a SecurityManager that blocks Unsafe. The attacker sends a stream of crafted OHTTP requests timed to coincide with legitimate concurrent OHTTP connections sharing the same Netty buffer pool arena. Because the HPKE AEAD operations receive the base address of pooled direct ByteBuffers instead of the correct offset address, BoringSSL reads key material and plaintext from adjacent buffer slots belonging to other connections; BoringSSL's zeroization of the output buffer on tag-verification failure then corrupts those adjacent slots, terminating the legitimate sessions. The leaked HPKE encryption key material disclosed through the out-of-bounds read allows the attacker to decrypt captured OHTTP traffic, directly defeating the anonymization Oblivious HTTP provides. No public POC exists at time of analysis.