CVE-2026-61798: 
Java vulnerability analysis and mitigation

CVE-2026-61798 is an information disclosure vulnerability in the io.netty.incubator:netty-incubator-codec-ohttp-hpke-classes-boringssl Maven package that exposes raw HPKE private key bytes through toString() methods and exception messages. All versions up to and including 0.0.22.Final are affected; the issue was fixed in 0.0.23.Final. The vulnerability was originally published by maintainer normanmaurer on July 12, 2026, and added to the GitHub Advisory Database on August 20, 2026. It carries a CVSS v3.1 base score of 8.1 (High) (GitHub Advisory, Netty Advisory).

The root cause is improper handling of sensitive cryptographic material in string serialization methods, classified under CWE-200 (Exposure of Sensitive Information), CWE-312 (Cleartext Storage of Sensitive Information), and CWE-532 (Insertion of Sensitive Information into Log File). Three specific code paths are responsible: (1) BoringSSLAsymmetricCipherKeyPair.toString() (lines 72–78) concatenates "privateKey=" + privateKey, (2) BoringSSLAsymmetricKeyParameter.toString() (lines 70–76) returns "bytes=" + Arrays.toString(bytes) regardless of whether isPrivate is true, and (3) BoringSSL.EVP_HPKE_KEY_init_or_throw() (lines 228–232) throws an IllegalArgumentException embedding Arrays.toString(privateKeyBytes) when key initialization fails. Because Java logging frameworks routinely invoke toString() on logged objects and persist exception messages, these paths deterministically place complete HPKE private key material into application logs or telemetry. Exploitation requires only low privileges — sufficient to trigger logging of key-pair objects or key initialization failures — and no user interaction (GitHub Advisory, Netty Advisory).

If an affected key pair or initialization exception is logged, application logs contain the complete HPKE private key material in cleartext, recoverable by anyone with log read access. This compromises the confidentiality of all OHTTP messages encrypted to the exposed key, undermines integrity and authenticity expectations for future messages if the key remains active, and complicates incident response because log retention may preserve key material long after in-memory rotation. The high confidentiality and integrity CVSS impact ratings reflect that a recovered private key enables decryption of past OHTTP traffic and potential impersonation (GitHub Advisory).

No public exploit code or active in-the-wild exploitation has been reported for CVE-2026-61798. The vulnerability is passive in nature — exploitation depends on an attacker gaining read access to application logs or telemetry systems where key-pair objects or key initialization exceptions have been logged. The CVE status is currently "Reserved" and no EPSS score or CISA KEV catalog entry is available at this time. The code path is deterministic and a proof-of-concept reproducer was included in the advisory, demonstrating that the private key bytes are always exposed when toString() is called on affected objects (GitHub Advisory, Netty Advisory).

1. Identify target application: Locate a Java application using io.netty.incubator:netty-incubator-codec-ohttp-hpke-classes-boringssl version <= 0.0.22.Final that performs OHTTP/HPKE operations and has logging enabled at DEBUG or INFO level.
2. Trigger key-pair logging: Cause the application to log a BoringSSLAsymmetricCipherKeyPair object — for example, by triggering a code path where the key pair is passed to a logger (e.g., logger.debug("Key pair: {}", keyPair)).
3. Trigger key initialization failure (alternative path): Submit a malformed or invalid private key to the HPKE initialization routine, causing EVP_HPKE_KEY_init_or_throw() to throw an IllegalArgumentException that is subsequently logged, embedding the raw private key bytes in the exception message.
4. Access application logs: Obtain read access to the application's log files, log aggregation system (e.g., ELK stack, Splunk), or telemetry pipeline where the log entries are stored.
5. Extract private key bytes: Search log entries for patterns such as privateKey=BoringSSLAsymmetricKeyParameter{bytes=[ or privateKeyBytes does not contain a valid private key: [ to recover the full private key byte array.
6. Decrypt OHTTP traffic or impersonate: Use the recovered private key to decrypt previously captured OHTTP ciphertext or to impersonate the server in future HPKE-based communications (GitHub Advisory).

• Logs: Application log entries containing the string privateKey=BoringSSLAsymmetricKeyParameter{bytes=[ — indicating a BoringSSLAsymmetricCipherKeyPair object was serialized to a log.
• Logs: Log entries containing privateKeyBytes does not contain a valid private key: [ followed by a numeric byte array — indicating a failed HPKE key initialization was logged with raw key material.
• Logs: Any log line matching the pattern BoringSSLAsymmetricCipherKeyPair{privateKey=BoringSSLAsymmetricKeyParameter{bytes=[...], isPrivate=true} in application or telemetry logs.
• Log Aggregation Systems: Queries in SIEM/log aggregation tools (Splunk, Elasticsearch) for the field patterns above across historical log retention windows, which may reveal key material persisted before patching (GitHub Advisory).

Upgrade io.netty.incubator:netty-incubator-codec-ohttp-hpke-classes-boringssl to version 0.0.23.Final, which redacts private key material from toString() outputs and exception messages (Netty Release). As an interim workaround for applications that cannot immediately upgrade, configure logging frameworks to suppress or redact log entries containing BoringSSLAsymmetricCipherKeyPair or BoringSSLAsymmetricKeyParameter objects, and avoid logging key-pair objects or HPKE-related exceptions at any log level. After patching, audit existing logs for exposed private key material and rotate any HPKE keys that may have been logged, as log retention may preserve key material indefinitely (GitHub Advisory).

The vulnerability was discovered and reported by Thai Son Dinh (sondt99) from VinSOC Labs (R&D) and published by Netty maintainer normanmaurer on July 12, 2026. No significant broader media coverage or notable public researcher commentary beyond the advisory itself has been identified at this time (Netty Advisory).