Is there a patch available for EUVD-2026-34308?

Yes, a patch is available for EUVD-2026-34308. Update the affected software to the latest version immediately.

Netty OHTTP EUVD-2026-34308

Q: What is the CVSS score of EUVD-2026-34308?

EUVD-2026-34308 has a CVSS 4.0 base score of 6.8 (Medium). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:H/SC:N/SI:N/SA:N/E:U/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.0%.

| CVE-2026-48040 MEDIUM

Out-of-bounds Read (CWE-125)

2026-06-04 GitHub_M

GHSA-32hf-8jw3-v4qq

Information Disclosure Java Buffer Overflow

6.8

CVSS 4.0 · GitHub Advisory

Severity by source

GitHub Advisory PRIMARY

6.8 MEDIUM

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:H/SC:N/SI:N/SA:N/E:U/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Primary rating from GitHub Advisory · only source for this CVE.

CVSS VectorGitHub Advisory

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:H/SC:N/SI:N/SA:N/E:U/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Lifecycle Timeline

Source Code Evidence Fetched

Jun 04, 2026 - 20:02 vuln.today

Analysis Generated

Jun 04, 2026 - 20:02 vuln.today

Patch available

Jun 04, 2026 - 19:01 EUVD

CVSS changed

Jun 04, 2026 - 18:22 NVD

6.8 (MEDIUM)

CVE Published

Jun 04, 2026 - 17:33 nvd

UNKNOWN (no severity yet)

DescriptionGitHub Advisory

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.

AnalysisAI

Incorrect native memory address resolution in Netty's Oblivious HTTP (OHTTP) BoringSSL JNI bridge allows unauthenticated remote attackers to corrupt memory belonging to concurrent connections and disclose the contents of adjacent pooled direct buffers - including HPKE encryption key material - on affected OHTTP gateways. The flaw exists in versions prior to 0.0.22.Final of netty-incubator-codec-ohttp and is only reachable when the JVM is configured to deny sun.misc.Unsafe access, causing the vulnerable fallback address-resolution path to activate. This directly undermines the confidentiality guarantees Oblivious HTTP is designed to provide; no public exploit code exists and the vulnerability is not listed in the CISA KEV catalog (CVSS 4.0 E:U).

Technical ContextAI

The affected library (CPE: cpe:2.3:a:netty:netty-incubator-codec-ohttp) implements Oblivious HTTP per RFC 9458 using BoringSSL's HPKE C implementation via JNI. Cryptographic operations require passing raw native (off-heap) memory addresses of Netty ByteBuf objects directly into BoringSSL's C routines. When hasMemoryAddress() returns true, Netty exposes the correct raw pointer; the vulnerability (CWE-125, Out-of-bounds Read - though the impact also encompasses out-of-bounds writes) lies in the fallback path that activates for PooledDirectByteBuf instances when sun.misc.Unsafe is unavailable: the old memory_address(buffer.internalNioBuffer(0, buffer.capacity())) call returned the base address of the underlying java.nio.ByteBuffer without adding the buffer's current readerIndex or writerIndex offset. BoringSSL AEAD seal/open operations therefore targeted position 0 of the underlying off-heap buffer rather than the actual data region, reading from and writing into adjacent pooled memory. The fix (commit 7ad38d5) introduces readerMemoryAddress() and writerMemoryAddress() helpers in BoringSSL.java that correctly add the buffer's current index before passing the address to JNI, and updates callers in BoringSSLAEADContext.java and BoringSSLCryptoOperation.java accordingly.

RemediationAI

The vendor-released patch is version 0.0.22.Final; upgrade the netty-incubator-codec-ohttp Maven or Gradle dependency to 0.0.22.Final or later. The fix commit is at https://github.com/netty/netty-incubator-codec-ohttp/commit/7ad38d5cc2827af7e067e5c1e1ac37cd4566dad9 and the security advisory at https://github.com/netty/netty-incubator-codec-ohttp/security/advisories/GHSA-32hf-8jw3-v4qq. If immediate patching is not possible, a targeted workaround is to ensure the JVM hosting the OHTTP gateway does not use -Dio.netty.noUnsafe=true, does not apply a SecurityManager policy blocking Unsafe access, and runs on a standard HotSpot JVM - this prevents the fallback code path from activating entirely. Trade-off: removing these JVM restrictions may weaken other security controls if they were intentionally applied; evaluate whether Unsafe restrictions serve other hardening goals in your environment before removing them.