The vulnerability is in Netty’s OHTTP codec, where an incorrect derivation of native memory addresses in the pooled direct ByteBuf fallback path allows an attacker to perform an out‑of‑bounds write in native memory. Exploitation can corrupt memory of other connections and reveal adjacent pooled buffer contents. The breach can lead to disclosure of encryption keys and compromise confidentiality and integrity of all traffic using the shared Netty buffer arena. The weakness maps to CWE‑125 (Out‑of‑Bounds Read) and CWE‑787 (Out‑of‑Bounds Write).

Versions of netty‑incubator‑codec‑ohttp earlier than 0.0.22.Final contain the flaw. When Netty is run with Unsafe disabled (‑Dio.netty.noUnsafe=true), a SecurityManager blocking Unsafe, or on non‑HotSpot JVMs, the library falls back to a path that uses direct ByteBufs lacking a memory‑address expose. An unauthenticated network attacker can send crafted OHTTP requests to an OHTTP gateway to trigger the fallback and exploit the vulnerability.

The CVSS score of 6.8 indicates a medium‑severity condition. EPSS is not available, and the issue is not listed in CISA’s KEV catalog, but the out‑of‑bounds native memory write is a serious flaw that can be triggered without authentication in the described configurations. Because the exploit relies on executing native code via BoringSSL’s JNI interface, a successful attack requires the vulnerable library to be loaded and the unsafe path to be enabled. Attackers would gain access to encryption keys, potentially enabling full data compromise for all connections sharing the buffer arena.