CVE-2026-48040 is a memory corruption and information disclosure flaw in the Netty incubator OHTTP codec, scored CVSS 9.1 (critical). It occurs when sun.misc.Unsafe is unavailable to Netty. The fix is version 0.0.22.Final of the native BoringSSL HPKE artifact, so upgrade anything older.
What's affected
The GitHub advisory says all versions before 0.0.22.Final are affected, and 0.0.22.Final is the patched version. The affected Maven artifact is io.netty.incubator:netty-incubator-codec-ohttp-hpke-native-boringssl.
The flaw appears only under particular JVM configurations, because it sits in a fallback path used when Netty cannot reach sun.misc.Unsafe. The advisory names three: starting the JVM with -Dio.netty.noUnsafe=true, a SecurityManager that restricts Unsafe access, and non-HotSpot JVMs. In those cases the default pooled allocator returns direct buffers that report no memory address.
The advisory lists no workaround other than upgrading. The NVD vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N.
How to check if you're exposed
Check whether you use the library at all.
Maven:
mvn dependency:tree -Dincludes=io.netty.incubator:netty-incubator-codec-ohttp-hpke-native-boringssl
Gradle:
gradle dependencies | grep netty-incubator-codec-ohttp
If it is present at a version below 0.0.22.Final, check your JVM flags next. Look at your startup scripts, container entry points and JAVA_TOOL_OPTIONS for -Dio.netty.noUnsafe=true, and note whether you run a non-HotSpot JVM or a restrictive SecurityManager.
If none of those apply, the fallback path described in the advisory should not be active. Do not rely on that for long. Upgrade, since configuration changes over time.
What to do now
- Search your builds for the OHTTP codec artifact and record its version.
- Upgrade to 0.0.22.Final or later and redeploy any OHTTP gateway.
- Review JVM flags and runtime choices that disable Unsafe, and note which services use them.
- Restart the gateway processes so the fixed native library is loaded.
- Check monitoring for crashes or odd errors on the gateway before the upgrade, which may hint at memory problems.
Why it matters
The record maps this to CWE-125, out of bounds read, and CWE-787, out of bounds write. The library calls native cryptographic code through JNI and passes it memory addresses. When the address of a buffer cannot be read the normal way, the fallback derived the wrong native pointer, according to the advisory.
The consequence in the advisory is that one connection's request can corrupt or disclose memory that belongs to other connections sharing the same buffer arena. A gateway is shared by design, so the blast radius is every client of that process. The record's KEV flag is false.
Quick check
Is CVE-2026-48040 exploited in the wild?
The record's KEV flag is false, and the pages I read do not say it is exploited. Treat it as a patch item and keep an eye on the advisory for changes.
Am I affected if Unsafe is available?
The advisory ties the flaw to the fallback path used when Unsafe is not available. Still upgrade, since the vulnerable code is present in older versions.
Sources
Last reviewed: 19 October 2026.
