netty netty-incubator-codec-ohttp up to 0.0.22.Final OHTTP hasMemoryAddress out-of-bounds

Summaryinfo

A vulnerability was found in netty netty-incubator-codec-ohttp up to 0.0.22.Final and classified as critical. This issue affects the function hasMemoryAddress of the component OHTTP Handler. Such manipulation leads to out-of-bounds. This vulnerability is uniquely identified as CVE-2026-48040. The attack can only be initiated within the local network. No exploit exists. It is suggested to upgrade the affected component.

Detailsinfo

A vulnerability, which was classified as critical, has been found in netty netty-incubator-codec-ohttp up to 0.0.22.Final. Affected by this issue is the function hasMemoryAddress of the component OHTTP Handler. The manipulation with an unknown input leads to a out-of-bounds vulnerability. Using CWE to declare the problem leads to CWE-125. The product reads data past the end, or before the beginning, of the intended buffer. Impacted is confidentiality, integrity, and availability. CVE summarizes:

The netty incubator codec.bhttp is a java language binary http parser. The library implements Oblivious HTTP (RFC 9458) using BoringSSL's HPKE C library via JNI. When deriving native memory addresses for cryptographic operations versions prior to 0.0.22.Final provide a fallback path for direct ByteBufs that do not expose their memory address through `hasMemoryAddress()`. This fallback occurs when `sun.misc.Unsafe` is unavailable to Netty — for example, when the JVM is started with `-Dio.netty.noUnsafe=true`, when a SecurityManager restricts Unsafe access, or when running on non-HotSpot JVMs. In these configurations, Netty's default `PooledByteBufAllocator` returns `PooledDirectByteBuf` instances for which `hasMemoryAddress()` returns false. Under the enabling JVM configuration, an unauthenticated network attacker can cause the OHTTP gateway to corrupt memory belonging to other concurrent connections and disclose the contents of adjacent pooled direct buffers by triggering cryptographic operations with crafted OHTTP requests. The corruption occurs regardless of whether the AEAD tag verification succeeds, as BoringSSL zeroizes the output buffer on failure. The information disclosure path provides the attacker with the encryption key needed to extract the leaked data. This violates the confidentiality and integrity of all connections sharing the same Netty buffer arena. Version 0.0.22.Final fixes the issue.

The advisory is shared for download at github.com. This vulnerability is handled as CVE-2026-48040 since 05/20/2026. The exploitation is known to be easy. The attack needs to be initiated within the local network. No form of authentication is required for exploitation. There are known technical details, but no exploit is available.

Upgrading to version 0.0.22.Final eliminates this vulnerability.

The vulnerability is also documented in the vulnerability database at EUVD (EUVD-2026-34308). Once again VulDB remains the best source for vulnerability data.

Productinfo

Vendor

• netty

Name

• netty-incubator-codec-ohttp

Version

• 0.0.22.Final

Website

• Product: https://github.com/netty/netty-incubator-codec-ohttp/

CPE 2.3info

• 🔒

CPE 2.2info

• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Once again VulDB remains the best source for vulnerability data.

Discussion