Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/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:L/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/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
Lifecycle Timeline
3DescriptionGitHub Advisory
HKDF_expand: returns non-NULL on failure. The byte[] is filled with zeros and has no way to distinguish success from failure. Since this output is used as HKDF key material for the response AEAD, a failure silently produces an all-zero key.
When EVP_HPKE_CTX_export fails it also returns an empty byte[] array filled with zeros. This byte[] feeds directly into OHttpCrypto.createResponseAEAD(...). A silent all-zero export secret would produce a deterministic, attacker-predictable AEAD key.
AnalysisAI
Silent cryptographic key failure in Netty's OHTTP codec exposes HPKE response encryption to full key prediction. When HKDF_expand or EVP_HPKE_CTX_export fails internally, the library returns a zero-filled byte array rather than propagating the error, and that all-zero material is consumed directly by OHttpCrypto.createResponseAEAD() without any validation. Any OHTTP response encrypted under a failure-induced all-zero AEAD key is fully decryptable by any attacker who knows this behavior exists - the key is deterministic and universal. No public exploit has been identified at time of analysis, and this CVE is not listed in CISA KEV.
Technical ContextAI
The affected component is the Maven package io.netty.incubator:netty-incubator-codec-ohttp (versions prior to 0.0.21.Final), which implements Oblivious HTTP (OHTTP) - a privacy-enhancing protocol that wraps HTTP requests inside HPKE (Hybrid Public Key Encryption) to conceal request metadata from the relay. The vulnerability stems from CWE-330 (Use of Insufficiently Random Values): two internal cryptographic operations - HKDF_expand (a key derivation step in RFC 5869) and EVP_HPKE_CTX_export (BoringSSL/OpenSSL's HPKE context export) - both return a non-null, zero-filled byte[] on failure rather than throwing an exception or returning null. Because the Java caller has no mechanism to distinguish a legitimate zero-byte output from a failure-state zero-fill, the all-zero material silently propagates into OHttpCrypto.createResponseAEAD(), which constructs the AEAD cipher used to encrypt the OHTTP response. This turns a cryptographic failure into a completely predictable, attacker-known encryption key (0x00...00), breaking the confidentiality guarantee of the OHTTP response channel.
RemediationAI
Upgrade to io.netty.incubator:netty-incubator-codec-ohttp version 0.0.21.Final, which is the vendor-released patch as confirmed by GHSA-f659-372h-6x3x. Update your Maven or Gradle dependency to specify 0.0.21.Final or later. If an immediate upgrade is not feasible, consider disabling or gating the OHTTP response path at the application layer so that OHTTP-protected responses are not served until the patch is applied - this avoids exposure of the predictable-key failure mode at the cost of disabling OHTTP functionality entirely. There is no viable cryptographic workaround short of patching, since the flaw is in the error-handling path of a low-level key derivation primitive. The advisory is available at https://github.com/netty/netty-incubator-codec-ohttp/security/advisories/GHSA-f659-372h-6x3x.
Same weakness CWE-330 – Use of Insufficiently Random Values
View allSame technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-34307
GHSA-f659-372h-6x3x