CVE-2026-48040: netty-incubator-codec-ohttp's Incorrect Native Pointer Derivation in Pooled Direct ByteBuf Fallback Leads to Out-of-Bounds Native Memory Access

Published Jun 4, 2026
·
Updated

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.

Other sources

The netty-incubator-codec-ohttp library implements Oblivious HTTP (RFC 9458) using BoringSSL's HPKE C library via JNI. When deriving native memory addresses for cryptographic operations, provides 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.

Why this matters: 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.

GitHub

Affected Software

3 affected componentsFixes available
maven/io.netty.incubator/netty-incubator-codec-ohttp<0.0.22.Final
Netty netty-incubator-codec-ohttp<0.0.22
maven/io.netty.incubator:netty-incubator-codec-ohttp-hpke-native-boringssl<0.0.22.Final
0.0.22.Final

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade maven/io.netty.incubator:netty-incubator-codec-ohttp-hpke-native-boringssl to a version that resolves this vulnerability.

    Fixed in 0.0.22.Final
  2. Upgrade

    Upgrade netty-incubator-codec-ohttp to a version that resolves this vulnerability.

    Fixed in 0.0.22.Final
  3. Configuration

    In netty-incubator-codec-ohttp versions prior to 0.0.22.Final, update the native pointer derivation logic to use a fallback path for direct ByteBufs where hasMemoryAddress() returns false, so cryptographic operations do not derive incorrect native pointers for pooled direct buffers.

    Netty PooledByteBufAllocator / BoringSSL HPKE JNI integration (netty-incubator-codec-ohttp) fallback for direct ByteBuf native memory address derivation when hasMemoryAddress() is false = enable fallback path for direct ByteBufs that do not expose their memory address via hasMemoryAddress()

Event History

Jun 4, 2026
CVE Published
via MITRE·05:33 PM
Data Sourced
via MITRE·05:33 PM
DescriptionWeakness
Data Sourced
via NVD·06:16 PM
RemedyDescriptionSeverityWeaknessAffected Software
Jun 11, 2026
Advisory Published
via GitHub·01:28 PM
Data Sourced
via GitHub·01:28 PM
DescriptionWeaknessAffected Software
Free Weekly Intel

Don't miss critical vulnerabilities

Join thousands of security professionals who receive our weekly digest of trending CVEs, zero-days, and exploited vulnerabilities.

No spam. Unsubscribe anytime.

Frequently Asked Questions

1

What is the severity of CVE-2026-48040?

CVE-2026-48040 has a medium severity rating of 6.8.

2

How do I fix CVE-2026-48040?

To fix CVE-2026-48040, update the netty-incubator-codec-ohttp library to version 0.0.22.Final or later.

3

What causes CVE-2026-48040?

CVE-2026-48040 is caused by incorrect native pointer derivation in Pooled Direct ByteBuf fallback leading to out-of-bounds native memory access.

4

Which software is affected by CVE-2026-48040?

The vulnerability affects the netty-incubator-codec-ohttp library, particularly versions prior to 0.0.22.Final.

5

Is there a patch available for CVE-2026-48040?

Yes, a patch is available for CVE-2026-48040 in the form of an updated library version.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203