Listen to this Post
The vulnerability resides in the `io.netty.incubator:netty-incubator-codec-ohttp-hpke-classes-boringssl` package, which implements Oblivious HTTP (RFC 9458) using BoringSSL’s HPKE C library via JNI. The flaw manifests through three distinct code paths that inadvertently expose raw HPKE private key material.
First, `BoringSSLAsymmetricCipherKeyPair.toString()` at lines 72-78 concatenates the string `”privateKey=”` with the private key object. This private key is an instance of `BoringSSLAsymmetricKeyParameter` created with isPrivate=true. Second, `BoringSSLAsymmetricKeyParameter.toString()` at lines 70-76 returns `”bytes=” + Arrays.toString(bytes)` without checking whether `isPrivate` is true, rendering the full byte array regardless of sensitivity. Third, a separate error path in `BoringSSL.EVP_HPKE_KEY_init_or_throw()` at lines 228-232 throws an `IllegalArgumentException` that includes `Arrays.toString(privateKeyBytes)` when BoringSSL rejects the key.
Java logging frameworks commonly call `toString()` on structured objects and persist exception messages to logs or telemetry systems. An application that logs key-pair objects or exceptions from failed key initialization will therefore write complete HPKE private key material into its logs. Anyone with access to those logs can recover the key. Depending on key reuse and log retention policies, this exposure can compromise the confidentiality of OHTTP messages encrypted to the exposed key, undermine integrity and authenticity expectations for future messages if the key remains active, and defeat key rotation assumptions when logs retain key material long after the in-memory key is rotated.
A minimal proof of concept demonstrates the deterministic nature of the issue:
package io.netty.incubator.codec.hpke.boringssl;
public final class VerifyPrivateKeyToString {
public static void main(String[] args) {
byte[] privateKey = new byte[] {1, 2, 3, 4};
byte[] publicKey = new byte[] {5, 6, 7, 8};
BoringSSLAsymmetricCipherKeyPair pair = new BoringSSLAsymmetricCipherKeyPair(privateKey, publicKey);
System.out.println(pair.toString());
}
}
The observed output includes the full private key byte array: BoringSSLAsymmetricCipherKeyPair{privateKey=BoringSSLAsymmetricKeyParameter{bytes=[1, 2, 3, 4], isPrivate=true}, publicKey=BoringSSLAsymmetricKeyParameter{bytes=[5, 6, 7, 8], isPrivate=false}}.
DailyCVE Form:
Platform: Java/Maven
Version: 0.0.3.Final to 0.0.21.Final
Vulnerability: Private Key Disclosure
Severity: High (CVSS 8.1)
Date: 2026-08-21
Prediction: 2026-06-03 (0.0.22.Final)
What Undercode Say:
Check affected version in Maven project mvn dependency:tree | grep netty-incubator-codec-ohttp-hpke-classes-boringssl Scan for vulnerable versions (0.0.3.Final through 0.0.21.Final) grep -r "netty-incubator-codec-ohttp-hpke-classes-boringssl" pom.xml Verify fix applied (0.0.22.Final or higher) mvn help:evaluate -Dexpression=project.version | grep -v "["
Exploit: (Educational Purposes!)
An attacker with access to application logs can extract the private key bytes from log entries containing:
– `BoringSSLAsymmetricCipherKeyPair.toString()` output
– `BoringSSLAsymmetricKeyParameter.toString()` output
– Exception messages from `EVP_HPKE_KEY_init_or_throw()`
The byte array appears as `[1, 2, 3, 4, …]` format and can be reconstructed to recover the complete HPKE private key.
Protection:
- Upgrade to version 0.0.22.Final or later
- Redact private key material in `BoringSSLAsymmetricKeyParameter.toString()` when `isPrivate` is true
- Redact `privateKey` in `BoringSSLAsymmetricCipherKeyPair.toString()`
– Remove `Arrays.toString(privateKeyBytes)` fromBoringSSL.EVP_HPKE_KEY_init_or_throw(); report only length and KEM metadata - Add regression tests asserting that `toString()` and exception messages do not contain private key byte values
- Consider making key pair classes avoid implementing detailed `toString()` for sensitive material entirely
Impact:
If an affected key pair or initialization exception is logged, application logs contain complete HPKE private key material. Anyone with access to those logs can recover the key. This compromises confidentiality of OHTTP messages, integrity and authenticity expectations for future messages if the key remains active, and incident response and key rotation assumptions when logs retain key material long after the in-memory key is rotated.
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
